Sikkerhetstesting Oppdatert 29. juni 2026
Det finnes ikke ett tall som passer alle. Hvor ofte dere bør teste sikkerheten avgjøres av to ting: hvor mye som endrer seg hos dere, og hvor mye dere har å tape. En fast dato i kalenderen er et gulv, ikke et svar.
Kort fortalt
En sikkerhetstest er et øyeblikksbilde. Den viser hvilke svakheter som fantes i de systemene som ble testet, slik de var satt opp den dagen testen ble gjennomført. Anerkjent bransjepraksis lander på minst én test i året som et fornuftig minimum. Men «én gang i året» bærer en stilltiende antakelse: at ingenting av betydning har endret seg på tolv måneder. For de fleste bedrifter stemmer ikke det.
En test forteller hvordan sikkerheten var den dagen den ble kjørt, ikke hvordan den er i dag.
Lanserer dere en ny funksjon, åpner en ny tjeneste mot internett eller flytter noe til sky uken etter testen, er øyeblikksbildet allerede utdatert på akkurat de punktene som er mest sannsynlige til å introdusere nye svakheter.
Kalenderen setter gulvet. Endring er det som faktisk bør utløse en ny test. En tommelfingerregel som holder: test hver gang dere gjør noe som endrer hva som er eksponert, eller hvordan det er bygget.
Typiske hendelser som bør utløse en test:
Felles for alle: de endrer angrepsflaten. En test som ble kjørt før endringen sier lite om risikoen etter den.
Den vanligste blindsonen er ikke hvor ofte man tester, men hva som skjer etterpå. En rapport full av funn har liten verdi hvis ingen bekrefter at rettingene virker. Et funn er ikke lukket fordi noen har gjort en endring i koden eller oppsettet. Det er lukket når en ny test viser at svakheten ikke lenger kan utnyttes.
Derfor hører en re-test med til enhver seriøs testing: først testen, så utbedringen, så en kontroll som bekrefter resultatet. Hopper dere over det siste steget, vet dere ikke om dere er tryggere. Dere håper det.
Det finnes ingen fasit som passer alle, men dette er en rytme som følger anerkjent praksis, og som de fleste mellomstore bedrifter kan styre etter. Det er en veiledning, ikke et regelverk dere må følge.
| Område | Når det bør testes |
|---|---|
| Internett-eksponert infrastruktur | Minst årlig, og ved endringer i oppsett eller eksponering |
| Webapplikasjoner og tjenester | Ved større releaser eller nye funksjoner, og minst årlig |
| Intern infrastruktur | Periodisk og risikobasert |
| Etter utbedring | Ny test som bekrefter at funnene er lukket |
Hvor på skalaen dere lander avhenger av hvor mye dere endrer, hvor sensitive data dere håndterer, og hva kunder og leverandører forventer. Stadig flere ber om dokumentert sikkerhet før de inngår avtale, og et nytt regelverk på sikkerhetsområdet er på vei.
Usikker på hvor dere står i dag? Sikkerhetsdiagnosen gir dere et ærlig nåbilde på noen minutter, uten innlogging og helt uforpliktende.
Vil dere ha en konkret plan for hva som bør testes og når, ser vi på det sammen under Sikkerhetstesting.
FAQOfte stilte spørsmål
Det avhenger av hvor mye som endrer seg hos dere. Etablert bransjepraksis er minst én gang i året som et minimum, kombinert med en test hver gang dere gjør vesentlige endringer i systemer, kode eller hva som er eksponert mot internett.
Bare hvis lite endrer seg. En årlig test fanger ikke svakheter som oppstår når dere lanserer nye funksjoner, flytter tjenester eller endrer oppsettet underveis. Da bør testen følge endringen, ikke kalenderen.
Ved vesentlige endringer: nye internett-eksponerte tjenester, større releaser eller nye funksjoner, flytting til sky, sammenslåinger og nye integrasjoner, eller endringer i nettverks- og brannmuroppsett.
Ja, hvis dere vil være sikre på at rettingen faktisk virker. Et funn er ikke lukket før en ny test bekrefter at det ikke lenger kan utnyttes.
VERNUM