«Ja, vi har gjort en risikoanalyse» – men har vi vurdert den riktige risikoen?

En risikoanalyse betyr ikke nødvendigvis at sikkerhetsrisikoen er godt nok vurdert. I mange IT-prosjekter handler risikovurderingen først og fremst om leveranse, kostnad og fremdrift – mens trusselaktører, angrepsvektorer og tilgjengelighet får mindre oppmerksomhet. Hva bør en testleder se etter?

Del 1 av 4: Hvorfor «har vi gjort en risikoanalyse?» ikke nødvendigvis er det riktige spørsmålet.

Dette er første del i en artikkelserie i fire deler om testlederens rolle i å sikre offentlige IT-systemer mot tjenestenektangrep. Del 2 tar for seg trusselbildet og regelverket, del 3 gir fem konkrete grep testledere kan ta i samarbeid med sikkerhet, og del 4 oppsummerer budskapet til ledelsen.

Spørsmålet som får et for enkelt svar

De fleste IT-prosjekter av en viss størrelse har en testleder. Og de fleste testledere har på et eller annet tidspunkt stilt det samme spørsmålet inn i prosjektledelsen: «Er det gjennomført en sikkerhetsrisikoanalyse?» Svaret kommer nesten alltid raskt: enten ja eller nei. Problemet er at et ja i praksis sier svært lite om hva som egentlig er vurdert. Skrap i overflaten, og man finner ofte en risikoanalyse som først og fremst handler om leveranse, kostnad og fremdrift – ikke om hvem som kan ønske å ramme systemet, hvordan de kan gjøre det og hvilke konsekvenser det kan få.

Dette er ikke en kritikk av prosjektledelsen. Det er en beskrivelse av en systematisk svakhet i hvordan mange offentlige IT-prosjekter er organisert: sikkerhet blir en boks som skal krysses av, ikke en dimensjon som gjennomsyrer testing, arkitektur og driftsplanlegging. Denne artikkelserien tar for seg hva testledere konkret kan gjøre for å tette dette gapet, med et særlig blikk på trusler mot tilgjengelighet, altså DDoS- og andre tjenestenektangrep (denial-of-service), som har blitt en av de mest aktuelle truslene mot norsk offentlig sektor.

Funksjonell risikoanalyse og sikkerhetsrisikoanalyse – to analyser som ofte forveksles

Det finnes en viktig, men underkommunisert, forskjell mellom en funksjonell risikoanalyse og en sikkerhetsrisikoanalyse. Den funksjonelle risikoanalysen ligger typisk i prosjektets risikoregister og handler om forsinkelser, budsjettoverskridelser, uklare krav, avhengigheter til andre prosjekter og brukeraksept.

Det er nyttig og nødvendig arbeid. Men det svarer ikke nødvendigvis på spørsmålene en sikkerhetsrisikoanalyse skal besvare: Hvem er de realistiske trusselaktørene? Hvilke angrepsvektorer er relevante? Og hva er sannsynligheten og konsekvensen dersom konfidensialitet, integritet eller tilgjengelighet blir brutt?

Tilgjengelighet er gjerne den dimensjonen som kommer dårligst ut i denne forvekslingen. Mange sikkerhetsvurderinger i offentlige IT-prosjekter handler i praksis først og fremst om personvern og konfidensialitet: Hvem kan få tilgang til data de ikke skal se?

Men hva skjer dersom tjenesten blir presset ned av et volumangrep, for eksempel gjennom et botnett? Eller dersom et sårbart API-endepunkt gjør tjenesten utilgjengelig?

Disse spørsmålene stilles sjeldnere eksplisitt – og testes enda sjeldnere.

I del 2 ser vi på hvorfor trusselbildet gjør dette spørsmålet mer akutt enn før, inkludert en fersk hendelse fra sommeren 2026, og hvilket ansvar regelverket legger på virksomhetens ledelse.