Hvilke regelverk krever regelmessig pentest, og hvordan dere løser det uten manuelt arbeid

Fem regelverk pålegger norske SMB-er å teste sikkerheten regelmessig. Bare ett av dem, og kun for en liten gruppe utpekte finansforetak, krever et manuelt red team. De fire andre kan dere svare på med kontinuerlig AI-testing, og på SMB-skala bør dere gjøre nettopp det.

TL;DR: DORA, NIS2, ISO 27001, PCI DSS og GDPR forventer alle sikkerhetstesting på regelmessig basis. Bare DORAs etterretningsledede penetrasjonstest, pålagt utpekte store finansforetak, må være et manuelt red team. For alt annet lukker en autonom AI-pentest som kjører kontinuerlig kravet, og leverer bedre bevis enn én årlig manuell rapport.

I avgrensningssamtalene jeg har kjørt dette kvartalet, dukker den samme misforståelsen opp gang på gang: et styre får høre at foretaket “må ha en årlig pentest” for ISO 27001, NIS2 eller PCI DSS, og budsjettet settes til ett manuelt oppdrag i året. Regelverkene sier ikke det. De sier test, og de sier gjenta. De sier nesten aldri hvordan, og de sier nesten aldri hvem.

Misforståelsen koster penger og gir dårligere sikkerhet. Her er hva reglene forlanger, og hva FM CyberSecurity kjører for det regelmessige laget.

DORA-testing, to lag i én forordning

Digital Operational Resilience Act setter to ulike testforpliktelser for finanssektoren, og de skal ikke blandes.

Det første laget er det generelle testprogrammet for digital motstandsdyktighet (DORA artikkel 24 og 25). Hvert finansforetak som er omfattet, skal kjøre et dokumentert testprogram som dekker sårbarhetsvurderinger, skanninger, nettverkstester, kildekodegjennomgang der det er relevant, scenariobaserte tester og ende-til-ende-testing. Systemer som støtter kritiske eller viktige funksjoner, testes minst én gang i året. Forordningen utpeker ikke penetrasjonstesting som den eneste akseptable metoden. Den forventer bevis for at kontrollene virker. Den norske DORA-loven og DORA-forskriften trådte i kraft 1. juli 2025.

Det andre laget er threat-led penetration testing, altså etterretningsledet penetrasjonstesting (TLPT, DORA artikkel 26 og 27). Her snakker vi om et manuelt red team-oppdrag, etterretningsledet, kjørt mot produksjonsmiljøer og gjentatt minst hvert tredje år. Plikten gjelder kun for finansforetak som Finanstilsynet peker ut basert på en risikovurdering av størrelse, markedsandel, IKT-risikoprofil og hvor kritiske tjenestene er for det øvrige finanssystemet. Globalt systemviktige institusjoner er automatisk omfattet. Den norske gjennomføringen går gjennom TIBER-NO, den lokale versjonen av EUs TIBER-EU-rammeverk, etablert av Norges Bank og Finanstilsynet sammen.

For å være tydelig på avgrensningen: FM CyberSecurity leverer ikke TLPT eller TIBER-NO-oppdrag. Slike tester krever sertifiserte red team-leverandører med fem års senior pentest-erfaring, trusseletterretning fra en ekstern leverandør, og forsikringsdekning skrevet inn i reglene (Joint RTS on TLPT, EBA). Dessuten er det et eget marked, og foretakene som kjører dette, er ikke SMB-er.

FM CyberSecurity dekker laget under. For det generelle testprogrammet etter artikkel 24 og 25 kjører vi Aikido AI Pentest kontinuerlig mot applikasjonene som er omfattet. Funnene mates inn i IKT-risikoregisteret, med artikkelhenvisninger i dokumentasjonspakken. Der sitter de fleste norske finansforetak.

For bildet artikkel for artikkel, og for hva dere sender til Finanstilsynet, går DORA-sjekklisten for norske finansforetak gjennom de ti stegene.

NIS2-testing, navngitt uten å bli navngitt

NIS2 bruker ikke ordet “pentest” noe sted i artikkel 21. Direktivet lister ti risikostyringstiltak og forventer at foretak vurderer effekten av disse tiltakene. Europakommisjonens gjennomføringsforordning 2024/2690 og den tekniske veilederen fra ENISA behandler sikkerhetstesting, inkludert penetrasjonstesting, som en av de viktigste metodene.

Oversatt til drift: NIS2 forventer testing på regelmessig basis, etter vesentlige endringer, og med resultater som mates tilbake i risikovurderingen. Direktivet sier ikke én gang i året. Det krever heller ikke et menneskelig team. Det forlanger bevis.

I Norge er det første NIS-direktivet innlemmet gjennom digitalsikkerhetsloven, i kraft fra 1. oktober 2025, med NSM som tilsynsmyndighet via sektormyndighetene. Den norske gjennomføringen av NIS2 er under arbeid hos Justis- og beredskapsdepartementet. Forvent testkrav som ligger tett på EUs gjennomføringsforordning.

For SMB-er som er omfattet av NIS2, treffer det regelmessige testkravet akkurat det en kontinuerlig AI-pentest er laget for: hver release, hver vesentlige endring, automatisk, med datostemplet revisjonsspor.

ISO 27001-testing, kontrollen i vedlegg A 8.29

ISO/IEC 27001:2022 har én kontroll i vedlegg A dedikert til sikkerhetstesting: vedlegg A 8.29, “Security testing in development and acceptance”. Kontrollen slår sammen to kontroller fra 2013-versjonen til ett krav om at testing skjer under utvikling og før akseptanse i produksjon.

Kontrollen sier ingen steder “årlig penetrasjonstest”. Den forventer en strukturert testprosess tilpasset risikoen: statisk analyse, dynamisk testing, sårbarhetsskanning, penetrasjonstesting der det er relevant. Revisor ser etter prosessen, testplanen og bevisene for at funn blir lukket. De ser etter om dere testet det dere bygde.

I en sammenstilt ISO 27001-tilstandsanalyse denne våren tok ett gap lengst tid å lukke, og det lå ikke på den tekniske siden. Kunden hadde betalt for en endags manuell pentest året før revisjonen, beholdt rapporten, og ansett saken som ferdig. Revisor ville se testing koblet til releasesyklusen, bevis for at det nye endepunktet som ble sendt ut to måneder tidligere også var testet, og en måte å vise det samme for neste release. En punktrapport fra året før svarer ikke på paragraf 8 i standarden, som handler om å gjøre jobben og ta vare på beviset.

ISO 27001-sjekklisten for norske SMB-er går gjennom avgrensning til sertifisering, steg for steg. Testsvaret i steg 7 er det samme vi anbefaler for NIS2: kjør testen mot hver release, automatisk, og legg beviset i ISMS-bevispakken.

PCI DSS, det ene rammeverket som navngir pentest

PCI DSS versjon 4.0.1 er det eneste av de fem rammeverkene som bruker ordet “penetration test” som direkte krav. Krav 11.4 pålegger intern penetrasjonstesting (11.4.2) og ekstern penetrasjonstesting (11.4.3) minst årlig, og etter enhver vesentlig endring i infrastruktur, applikasjoner eller segmenteringskontroller. Alle v4.0-kravene med utsatt frist ble obligatoriske 31. mars 2025, så enhver brukersted eller tjenesteleverandør som håndterer kortdata i 2026, opererer under det fulle kravet.

Standarden sier ikke at et menneske må gjøre jobben. PCI Security Standards Councils veileder for penetrasjonstesting beskriver metodikk, avgrensning og forventninger til rapportering. Den foreskriver ikke testeren. Det som teller, er kvalifisert testing, dekning av riktig omfang, og ny avgrensning etter vesentlige endringer. Utløseren “etter vesentlige endringer” er der årlige manuelle tester sakker raskest etter virkeligheten: en ny betalingsflyt som ble sendt ut i juni, blir ikke testet før neste årlige oppdrag.

For PCI DSS lukker kontinuerlig AI-testing begge klokkene samtidig. Den årlige plikten dekkes av kjøringen som fullføres innenfor vurderingsvinduet. Endringskravet dekkes fordi testen kjøres på nytt automatisk når endringen skjer.

GDPR, indirekte men reelt

GDPR krever ikke pentest. Artikkel 32 krever tekniske og organisatoriske tiltak tilpasset risikoen, og lister “en prosess for regelmessig testing, vurdering og evaluering av effekten” av tiltakene som ett eksempel. Datatilsynet behandler i tilsynspraksis manglende testing som bevis på utilstrekkelig gjennomføring av artikkel 32 når et brudd har skjedd. Risikoen melder seg altså etter hendelsen, og ikke i regelteksten.

Kjører dere allerede kontinuerlig testing for ett av de fire rammeverkene over, lukkes artikkel 32-forpliktelsen i GDPR i samme bevegelse. Da har dere billig forsikring på kjøpet.

Hva FM CyberSecurity leverer, og hvorfor vi valgte denne leveransemodellen

FM CyberSecurity leverer pentest utelukkende gjennom Aikido AI Pentest. Ingen manuell pentest av web, mobil, nettverk, red team eller sosial manipulering. Beslutningen er bevisst og dokumentert, og bakgrunnen ligger i Hvorfor vi valgte Aikido: på SMB-skala produserer kontinuerlig AI-testing bedre bevis, koster mindre per funn, og samsvarer med hvordan regelverkene leser på papiret.

Tre kvantifiserte observasjoner fra de siste to kvartalene med tilstandsanalyser:

I fire ISO 27001-tilstandsanalyser i år lå tiden for å lukke gapet på sikkerhetstestingskontrollen (vedlegg A 8.29) mellom tre og seks uker. De tekniske rettelsene tok kortere tid enn dokumentasjonen. Kontinuerlig testing produserer dokumentasjonen som et biprodukt av kjøringen.

I et sammenstilt NIS2-avgrensningsoppdrag dette kvartalet med en SMB innen produksjon var testprogrammet de hadde tenkt å sende tilsynet “én ekstern pentest per år”. Det svaret hadde falt på “regelmessig”-ordlyden i gjennomføringsforordningen første gang en vesentlig endring ble sendt ut mellom testene. Ved å gå over til kontinuerlig testing endret de dokumentasjonen, ikke omfanget.

I seks sammenstilte applikasjonsgjennomganger denne våren fanget AI-pentesten autentiserings- og autorisasjonsfeil, IDOR-er og brutt tilgangskontroll, i samme dybde som et typisk endags manuelt oppdrag ville ha funnet det. Forskjellen lå i ny kjøring: da utvikleren sendte ut rettelsen, ble testen kjørt på nytt samme dag, ikke neste år.

For den regulatoriske innrammingen kobler FM CyberSecuritys compliance-praksis kravet mot testprogrammet på et lesbart språk, med artikkelhenvisninger i dokumentasjonspakken. Den tekniske testingen kjører parallelt. De to er ikke samme oppdrag.

For dere som vil se hvordan pentest passer inn i en bredere ISO 27001-bevispakke, går Pentest som del av ISO 27001-beviset gjennom rollen til testingen ved siden av vedlegg A og paragraf 8.

For å være tydelig på hva vi ikke gjør: TLPT for utpekte DORA-foretak etter artikkel 26 og 27 er et manuelt red team-oppdrag, og FM CyberSecurity leverer det ikke. Er foretaket deres pekt ut av Finanstilsynet for TLPT, trenger dere en TIBER-NO-leverandør fra den kvalifiserte listen. Vi kan hjelpe dere med resten av testprogrammet rundt det.

Hva det koster dere å overse dette

Tre ting går galt når “årlig manuell pentest”-rammen får stå på SMB-skala.

Punktproblemet: testen består i mai, den nye funksjonen sendes ut i juli, og revisjonen i november finner en utestet produksjonsendring. Revisor skriver et avvik. Sertifikatet står i fare.

Kostnadsproblemet: en meningsfull manuell ekstern pentest til norske rater havner i høye femsifrede til lave seksifrede beløp per oppdrag, og de fleste SMB-er har ikke råd til å kjøre den mer enn én gang i året. Kontinuerlig AI-testing passer inn i et årlig budsjett som kjøper mer dekning, ikke mindre.

Bevisproblemet: en PDF-rapport fra året før er ett datapunkt. En logg fra kontinuerlig testing er et datostemplet register over hver test, hver endring, hver rettelse, hver nye kjøring. Revisor foretrekker det siste.

Misforståelsen lar seg rette. Les hva rammeverket sier på papiret, velg testmodellen som leverer beviset, og slutt å betale én gang i året for noe forordningen aldri krevde.

Hvis dette traff

• Les DORA-sjekklisten for norske finansforetak eller ISO 27001-sjekklisten for norske SMB-er for bildet rammeverk for rammeverk.
• Send denne til compliance-ansvarlig eller personvernombud før neste revisjonsutvalg.
• Ta direkte kontakt med Christian i FM CyberSecuritys analyse-praksis for en gjennomgang på 30 minutter av hvordan kontinuerlig testing kobles mot deres konkrete rammeverksforpliktelser.