I nogle IT-projekter er sikkerhedstesten det sidste punkt før lanceringen, og det er også det første, der forsvinder, når projektet er forsinket og pengene er brugt. Ledelsen kan forhindre det ved at gøre testen til en fast post i budgettet, allerede når projektet godkendes. Beslutningen hviler på et enkelt greb: testen og tiden til at rette fundene skal have deres egen linje, som projektet ikke selv kan flytte.
Det kræver ingen teknisk viden. Det kræver, at ledelsen stiller spørgsmålet, før budgettet bliver vedtaget, og ikke når løsningen er færdig.
Projekter bliver ikke nødvendigvis billigere eller hurtigere end planlagt. Når pengene og tiden slipper op, skærer projektlederen i det, der ligger sidst og ikke er synligt for brugerne. Sikkerhedstesten opfylder begge betingelser.
Det kan ske uden en egentlig beslutning. Testen bliver skubbet til efter lanceringen, og efter lanceringen er projektet lukket, holdet opløst og budgettet væk. Løsningen kører i drift uden at være undersøgt, og ingen har sagt ja til den risiko. → Ny digital forretning
Gør testen til en betingelse i godkendelsen
Når ledelsen godkender et projekt, kan den stille krav til, hvad budgettet skal rumme. Gør testen til et af kravene for de projekter, hvor det er relevant.
- En linje til testen · med et omfang, der passer til løsningen, og en placering i tidsplanen før lanceringen.
- En linje til rettelser · tid og penge til at gøre noget ved fundene, før løsningen går i drift.
- En linje til kontrol · en efterprøvning af, at de alvorlige fund faktisk er lukket.
- En regel for ændringer · projektet kan ikke selv flytte eller fjerne posterne; det kræver ledelsens accept.
Den sidste regel er den vigtigste. Den gør det til en ledelsesbeslutning at springe testen over, i stedet for noget, der sker i stilhed.
Posterne behøver ikke være præcise, når projektet godkendes. Omfanget af testen afhænger af, hvordan løsningen ender med at se ud, og det kendes ikke altid helt fra starten. Et skøn, der justeres undervejs, er bedre end en tom linje. Det afgørende er, at pengene er reserveret, og at projektet ved, at de ikke må bruges til noget andet. Bed projektlederen om at melde tilbage, hvis løsningen vokser, så skønnet kan følge med. → Afsæt penge til rettelserne
Hvilke projekter skal have en test?
Ikke alle projekter behøver en sikkerhedstest. En ny intern rapport eller et skifte af kontorprogram kræver det ikke nødvendigvis. Ledelsen kan bruge få kriterier til at afgøre det:
- Kan løsningen nås udefra? En portal, en webshop eller en adgang for partnere er synlig for flere end jeres egne medarbejdere.
- Behandler den oplysninger, I skal beskytte? Personoplysninger, betalinger og forretningshemmeligheder vejer tungt.
- Står driften stille uden den? Systemer, som produktion, salg eller kundeservice afhænger af, fortjener ekstra opmærksomhed.
- Har en kunde eller en aftale krav til den? Så skal der også bruges dokumentation.
Svarer projektet ja til et eller flere af spørgsmålene, bør testen stå i budgettet. Kriterierne kan skrives ind i virksomhedens projektmodel, så de bliver stillet hver gang. → Kronjuvelerne
Sikkerhed fra starten, også efter GDPR
Behandler projektet personoplysninger, er der en ekstra grund til at tænke sikkerheden ind fra begyndelsen. Databeskyttelsesforordningens artikel 25 om databeskyttelse gennem design siger, at den dataansvarlige skal gennemføre passende tekniske og organisatoriske foranstaltninger både på tidspunktet for fastlæggelse af midlerne til behandlingen og på tidspunktet for selve behandlingen. Artikel 32 nævner desuden en procedure for regelmæssig afprøvning, vurdering og evaluering af, om foranstaltningerne virker.
Bestemmelserne kræver ikke en bestemt test, og en test opfylder dem ikke i sig selv. Men de understreger, at sikkerheden skal overvejes, mens løsningen bliver til, og ikke først når den kører. Teksten er ikke juridisk rådgivning. → Persondata og sikkerhedstest
Når en leverandør bygger løsningen
Bygger et bureau eller en softwareleverandør løsningen, skal testen også stå i aftalen med dem. Ledelsen bør sikre sig, at løsningen må testes af en uafhængig part, at leverandøren medvirker og retter alvorlige fund, og hvad det koster.
Hvis rettelserne ikke er beskrevet i aftalen, risikerer projektet at stå med en rapport og et tilbud på ekstraarbejde, som budgettet ikke kan bære. Det er lettere at forhandle, før kontrakten er skrevet under. → Leverandørens tilbud på rettelser
Hvem ejer løsningen, når projektet lukker?
Et projekt slutter, men løsningen lever videre. Fund, der ikke blev rettet før lanceringen, og den næste test af løsningen skal have en ejer i driften. Ellers forsvinder de, når projektgruppen går hver til sit.
Det gælder også dokumentationen. Rapporten, aftalerne om rettelser og eventuelle accepterede risici skal ligge et sted, hvor systemejeren kan finde dem. Gør det til en del af projektets afslutning, at åbne fund og fremtidige test bliver overdraget til en navngiven systemejer, og at løsningen bliver skrevet ind i virksomhedens testplan. → Flerårig testplan
Et tænkt eksempel
En boligforening vil give beboerne en portal, hvor de kan booke vaskeri, se dokumenter og melde fejl. Bestyrelsen godkender projektet med tre faste poster: en test før portalen åbner, tid til rettelser og en kort efterprøvning. Det står i godkendelsen, at posterne kun kan ændres med bestyrelsens accept.
Projektet bliver forsinket, og leverandøren foreslår at teste efter åbningen. Projektlederen må gå til bestyrelsen med forslaget. Bestyrelsen vælger at flytte åbningen et par uger i stedet, fordi portalen rummer oplysninger om beboerne. Beslutningen og begrundelsen står i referatet.
Det skal I lade være med
- At lægge testen sidst uden egen budgetlinje · så bliver den skåret væk, når projektet er presset.
- At budgettere testen uden rettelser · en rapport uden tid til at rette ændrer intet.
- At lade projektet flytte posten selv · fravalget skal være ledelsens.
- At glemme leverandøraftalen · ret til test og pligt til at rette skal stå i kontrakten.
- At lukke projektet uden en ejer af fundene · åbne punkter forsvinder med projektgruppen.
Hvad kan og ikke kan konkluderes
En fast post i projektbudgettet gør det langt mere sandsynligt, at nye løsninger bliver testet, før de går i drift, og at der er råd til at rette. Den siger intet om, hvor grundig testen bliver, eller om løsningen er sikker efter lanceringen. Nye funktioner og ændringer kræver, at løsningen bliver set på igen.
Tjekliste til godkendelse af projekter
- ☐ Har projektet svaret på kriterierne for, om det skal testes?
- ☐ Står test, rettelser og efterprøvning som egne poster i budgettet?
- ☐ Kan posterne kun ændres med ledelsens accept?
- ☐ Er test og rettelser beskrevet i aftalen med leverandøren?
- ☐ Er det aftalt, hvem der ejer åbne fund, når projektet lukker?
Kilder
- Databeskyttelsesforordningen (EU) 2016/679: artikel 25, stk. 1, om databeskyttelse gennem design, og artikel 32, stk. 1, litra d, om en procedure for regelmæssig afprøvning, vurdering og evaluering.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til ledelsen
Læs også: Test før I investerer i ny sikkerhed · Sikkerhed bremser forretningen
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
