ISO 27001 krever ikke penetrasjonstest

ISO/IEC 27001 er den internasjonale standarden for ledelsessystemer for informasjonssikkerhet. Den norske utgaven er NS-EN ISO/IEC 27001:2023, publisert i august 2023, og svarer til ISO/IEC 27001:2022.

Standard Norge beskriver kravene slik: virksomheten skal etablere retningslinjer for informasjonssikkerhet, identifisere og håndtere risiko, og iverksette relevante sikkerhetstiltak. Siste utgave har 93 tiltak, fordelt på fire kategorier: organisatoriske, personellrelaterte, fysiske og teknologiske.

Vi har ikke lest standardteksten selv. Den er betalingsbelagt, og iso.org svarte HTTP 403 på våre forespørsler. Alt vi skriver om standarden på denne siden bygger derfor på Standard Norge sine offentlige beskrivelser, og det er en begrensning dere bør regne med i det som følger.

Standard Norge sin egen beskrivelse av ISO/IEC 27001 nevner verken penetrasjonstest eller sikkerhetstesting. Den nevner retningslinjer, risiko og tiltak.

Det henger sammen med hvordan standarden er bygget. Kravene er generiske og skal kunne brukes av alle virksomheter uavhengig av type, størrelse og art. Et krav om at alle skal kjøpe penetrasjonstest ville stått i direkte motstrid til det, fordi det ville pålagt et bestemt tiltak uavhengig av risiko.

Standarden gjør noe annet, og noe strengere: den krever at dere kan gjøre rede for valgene deres. Hvilken risiko dere har vurdert, hvilke tiltak dere har valgt ut fra den, og hvorfor dere eventuelt har valgt bort et tiltak.

To av tiltakene i vedlegg A er de folk pleier å mene når de sier at standarden krever testing. Det ene handler om håndtering av tekniske sårbarheter. Det andre handler om sikkerhetstesting i utvikling og akseptanse.

Ingen av dem sier penetrasjonstest hvert år. Det første forventer at dere identifiserer sårbarheter, prioriterer dem og gjør noe med dem, ikke at dere har null. Det andre forventer at sikkerhetstesting er en del av utviklingsløpet, tilpasset systemet og eksponeringen.

Tiltaksnumrene 8.8 og 8.29 sirkulerer for disse to. Vi gjengir dem her fordi de er nyttige å søke på, men vi har ikke kunnet kontrollere nummereringen mot standardteksten, og fører den derfor ikke opp som bekreftet.

Sammenhengen standarden er bygget rundt er enkel å formulere og vanskelig å jukse med: en identifisert risiko, et valgt tiltak, og et bevis for at tiltaket virker.

En testrapport kan være beviset i det siste leddet. Men en rapport med åpne funn som ingen har lukket, dokumenterer det motsatte av det den skulle dokumentere. Den viser at dere fant noe og lot det ligge.

Derfor er en kortere test der funnene faktisk er rettet, mer verdt i denne sammenhengen enn en lang rapport som ligger i en mappe. Det er også billigere.

Har dere en applikasjon med innlogging, er en test som regel den korteste veien til å vise at tilgangskontrollen faktisk holder. Det er ikke noe verktøy som svarer på om bruker A kan hente ut data som tilhører bruker B, fordi verktøyet aldri var logget inn som noen av dem.

Har dere ingen egen applikasjon, og spørsmålet bare er hva som er synlig utenfra, er den gratis eksterne sjekken sannsynligvis nok til å komme i gang. Den leser DNS, e-postoppsett, sertifikat og svarhoder og sier hva som er galt.

Kjøp en test fordi dere vil vite svaret, og bruk rapporten som dokumentasjon i tillegg. Ikke omvendt.

Det finnes ett norsk regelverk som faktisk stiller et konkret krav om penetrasjonstesting, og det er DORA. DORA-loven, LOV-2025-05-27-18, trådte i kraft 1. juli 2025 sammen med DORA-forskriften, og gjør forordning (EU) 2022/2554 gjeldende som norsk lov for finanssektoren. Finanstilsynet er tilsynsmyndighet.

Finanstilsynet skriver at finansforetak, med noen unntak, skal gjennomføre trusselbasert penetrasjonstesting, og at testen minimum skal gjennomføres hvert tredje år. Forordningens artikkel 26 knytter samtidig plikten til at tilsynsmyndigheten peker ut hvilke foretak den gjelder for. De to formuleringene trekker litt i ulik retning, og vi har notert det som uavklart under.

Sikkerhetsloven, LOV-2018-06-01-24, i kraft 1. januar 2019, gjelder virksomheter av betydning for nasjonale sikkerhetsinteresser. Det er et eget spor med egne krav, og det er ikke ISO 27001.

Personopplysningsloven gjennomfører GDPR. Artikkel 32 nr. 1 bokstav d krever en prosess for regelmessig testing, analysering og vurdering av hvor effektive behandlingens tekniske og organisatoriske sikkerhetstiltak er. Det er et krav om å teste noe, jevnlig, men det står ingenting om metode eller frekvens.

Den største svakheten ved denne siden er at standarden er betalingsbelagt. Vi har ikke lest den, og vi sier det heller enn å skrive som om vi hadde.

Den eksterne sjekken leser det som er synlig utenfra og gir dere funnene med en gang, uten innlogging og uten e-postadresse.