Slik pentester vi apper som del av ISO 27001-arbeidet

Slik produserer FM CyberSecurity pentest-dokumentasjon som holder mot ISO 27001, gjennom Aikido AI Pentest, og uten å sette opp et manuelt pentest-oppdrag.

ISO 27001:2022 vedlegg A-tiltak 8.29, “Sikkerhetstesting i utvikling og akseptanse”, er det de fleste styringssystemer for informasjonssikkerhet (ISMS) henger pentest-bevisene sine på. Tiltaket godtar kodegjennomgang, skanning og penetrasjonstesting som gyldige metoder, og standarden krever ingen menneskelig tester. Revisor vil ha dokumentert testing, en definert utløser, og et bevisspor som kan følges.

1. Koble appoversikten til ISMS-omfanget

List opp hvilke apper som ligger innenfor ISMS-omfanget dere skrev i steg 1 av vår ISO 27001-sjekkliste. Vedlegg A 8.29 gjelder kun systemer som ISMS-et dekker. Et SaaS-selskap på 30 personer har typisk én eller to produksjonsapper, et kunde-API og et internt admin-verktøy omfattet av ISMS-et.

Skriv lista på én side: appnavn, URL eller repo, ansvarlig, omfattet ja eller nei. Denne lista blir populasjonen revisor trekker stikkprøve fra når de tester 8.29.

2. Koble Aikido AI Pentest til de omfattede appene

Koble hver omfattet app til Aikido. For en webapp gir dere Aikido mål-URL pluss testbrukere. For et API peker dere på OpenAPI- eller GraphQL-skjemaet, slik at agentene tester både dokumenterte og udokumenterte endepunkter.

Aikidos agenter oppdager, utnytter og bekrefter sårbarheter mot målet i drift før noe funn lander i rapporten. Det er valideringssteget som gjør resultatet fra en skanner om til pentest-bevis.

3. Sett testtakten: kontinuerlig og før produksjon

Vedlegg A 8.29 forventer testing under utvikling og ved akseptanse. Sett opp Aikido på to utløsere: kontinuerlig (ved hver kodeendring på main, eller etter en fastlagt plan) og før produksjon (som siste sjekk før utrulling, slik at en release stanser når funn er bekreftet utnyttbare). Aikido Infinite, lansert i februar 2026, kjører det kontinuerlige sporet. Skriv testtakten inn i testplanen i ISMS-et, slik at policyen og systemet sier det samme.

4. Samle bevissporet

Hver Aikido-kjøring produserer en PDF-rapport som holder mot revisjon, med validerte funn, utnyttelsesbevis, reproduksjonssteg og utbedringsforslag, strukturert mot forventningene i ISO 27001. Lagre rapportene der ISMS-dokumentindeksen kan peke til dem, én oppføring per app per kvartal.

Hold tre felter ved siden av hver rapport: kjøredato, hvilken versjon eller bygg som ble testet, og saken som lukket eventuelle funn. De tre knytter beviset til en konkret release, og den tråden følger revisor.

5. Koble Aikido-resultatet til vedlegg A 8.29 i SoA-en

I Statement of Applicability (SoA) navngir linja for 8.29 Aikido AI Pentest som kontrollmekanisme, peker til testplanen og refererer til bevismappa. Én setning holder: “Sikkerhetstesting i utvikling og akseptanse leveres gjennom Aikido AI Pentest. Kontinuerlige kjøringer ved hver release, kjøringer før produksjon som siste sjekk før utrulling. Rapporter oppbevares etter dokumentpolicyen.”

Er en omfattet app utviklet av en tredjepart, gjelder dessuten vedlegg A 8.30 “Utkontraktert utvikling”. Samme Aikido-bevis dekker 8.30 der dere kontrollerer testmålet selv, mens leverandørkontrakten bærer forpliktelsen der dere ikke gjør det.

6. Slik leser revisor beviset i trinn 1 og trinn 2

I trinn 1 leser revisor testpolicyen, SoA-linja, omfangslista, og minst én eksempelrapport. Bestått betyr at dokumentasjonen henger sammen, altså at policyen navngir Aikido, omfangslista stemmer med SoA-en, og en eksempelrapport finnes.

I trinn 2 tar revisor stikkprøve i det driftede systemet, plukker to eller tre apper fra omfangslista og ber om siste rapport på hver. De sjekker datoen mot den oppgitte testtakten og ser etter lukkebevis på hvert funn med høy alvorlighet. Vær forberedt på ett spørsmål: “Hva skiller dette beviset fra en sårbarhetsskanning?” Svaret er at Aikido bekrefter utnyttbarhet mot målet i drift før et funn rapporteres, og nettopp dette gjør at resultatet teller som penetrasjonstesting under 8.29 og ikke skanning under 8.8. For hvorfor dette er det eneste pentest-mønsteret vi kjører, se hvorfor vi valgte Aikido.

7. Hold det i gang etter sertifisering

Tilsynsrevisjoner i år én og to trekker stikkprøve fra samme 8.29-bevis. Hold Aikido i gang på de samme utløserne og rapportene i samme mappestruktur, så blir tilsynet en sak om å hente fram siste prøve. Endres omfanget (ny app inn, gammel app ut), oppdater omfangslista og Aikido-konfigurasjonen samme uke, slik at de to holder seg synkronisert.

Neste steg

Ta direkte kontakt med Christian i analyse-praksisen vår for en ISO 27001-modenhetsgjennomgang på testsiden: en kobling fra omfang til Aikido, et utkast til SoA-linje for 8.29, og en testplan dere kan drifte selv.

FAQ

Godtar revisor AI-pentest som bevis for vedlegg A 8.29?

Ja, når resultatet er en validert penetrasjonstest-rapport med utnyttelsesbevis, ikke en sårbarhetsskanning. Tiltaket navngir penetrasjonstesting som én godtatt metode og krever ingen menneskelig tester. Aikidos rapporter inkluderer reproduksjonssteg og utnyttelsesbekreftelse for hvert funn, og det er dette revisor leser når de avgjør om beviset holder. For den løpende testforpliktelsen under andre regelverk, se regelverk som krever regelmessig pentest.

Hva om revisor vil ha et årlig pentest-brev?

Noen revisorer drar med seg en vane fra 2013-versjonen, der artefakten var et årlig brev fra et pentest-firma. Tiltakteksten fra 2022 er metode-nøytral, og kontinuerlig testing med daterte rapporter per release gir et sterkere bevisspor enn ett brev i året. Vil revisor likevel ha et samlet sammendrag, eksporter en årlig oppsummering fra Aikido som dekker årets kjøringer, funn og lukkinger.

Hvordan fungerer dette for SaaS dere ikke laget selv?

Dere kan ikke kjøre pentest mot en leverandørs app uten tillatelse, og de fleste kontrakter forbyr det. Vedlegg A 8.29 forventer at dere bekrefter at leverandøren tester sin egen programvare, vanligvis ved å hente inn SOC 2 Type II-rapporten eller ISO 27001-sertifikatet deres pluss et pentest-sammendrag. Kjør Aikido mot det dere selv kontrollerer, altså deres egne apper som integrerer med SaaS-en, og tenant-konfigurasjonen deres der leverandøren tilbyr et API. Vedlegg A 8.30 bærer resten av forpliktelsen gjennom leverandørkontrakten.

Hva om appen har APIer og ikke bare et brukergrensesnitt?

Aikido tester APIer sammen med brukergrensesnittet. Pek den mot OpenAPI- eller GraphQL-skjemaet deres, så dekker agentene de dokumenterte endepunktene og sonderer deretter etter udokumenterte. Bevissporet og rapportstrukturen er de samme som for en app med brukergrensesnitt.