NIS2, ISO 27001 och det regulatoriska trycket

Regulatoriska krav är inte den enda anledningen att testa regelbundet, men de gör det svårt att låta bli. NIS2-direktivet, som trädde i kraft i EU och nu implementeras i svensk lag, ställer explicita krav på systematisk riskhantering och säkerhetsutvärdering för organisationer inom kritisk infrastruktur och viktiga samhällsfunktioner. Direktivet specificerar inte exakt "gör pentest varje år", men kravet på löpande riskbedömning och tekniska säkerhetsåtgärder gör det i praktiken svårt att argumentera mot regelbunden testning.

ISO/IEC 27001:2022 är ännu tydligare. Standarden kräver att organisationer regelbundet utvärderar effektiviteten i sina säkerhetsåtgärder. Ett årligt pentest är det mest konkreta sättet att verifiera att era kontroller faktiskt fungerar i praktiken – inte bara på papper.

Vad Integritetsskyddsmyndigheten (IMY) förväntar sig

IMY har i flera tillsynsbeslut betonat att organisationer som behandlar känsliga personuppgifter förväntas genomföra regelbundna säkerhetstester. GDPR artikel 32 kräver "ett förfarande för att regelbundet testa, undersöka och utvärdera effektiviteten hos de tekniska och organisatoriska åtgärderna". Pentest är det mest direkta svaret på den formuleringen.

Pentestets cykel: från planering till verifiering

Effektiva återkommande pentest följer en tydlig cykel som förbättras varje iteration. Här är processen vi tillämpar i Opsios säkerhetsarbete:

1. Scope och riskprioritering

Varje testcykel börjar med att definiera vad som testas och varför. Scope bör styras av riskanalys, inte av vana. Frågor att ställa:

• Vilka system har förändrats sedan senaste testet?
• Vilka nya tjänster eller integrationer har tillkommit?
• Var ligger den högsta affärsrisken om ett intrång sker?
• Har tidigare identifierade brister faktiskt åtgärdats?

En vanlig fälla är att testa samma scope varje år. Det ger en falsk trygghet. En bättre strategi är att rotera fokus mellan extern attack mot perimetern, intern testning (insider-scenario), applikationstester och molnkonfigurationsgranskning.

2. Genomförande med rätt testtyp

Olika situationer kräver olika testtyper. Valet beror på vad ni vill validera:

Vår rekommendation: börja med grey box för webbapplikationer och extern black box för infrastruktur. Organisationer som redan har ett moget säkerhetsprogram bör komplettera med red team-övningar, gärna i samverkan med ert SOC för att validera detektionsförmågan.

3. Rapportering som driver förändring

En pentest-rapport som ingen agerar på är bortkastad tid. Rapporteringen behöver tala till flera målgrupper:

• Ledningen – sammanfattning av affärsrisk, inte tekniska detaljer. Vad kan hända och vad kostar det?
• Säkerhetsansvariga – riskklassificerade fynd med tydlig prioritering
• Utvecklare och driftteam – specifika åtgärdsrekommendationer med tillräcklig teknisk detalj för att faktiskt fixa problemet

4. Åtgärd och verifiering

Här faller många organisationer. Rapporten läses, presenteras för ledningen och läggs sedan i en mapp. Återkommande testning löser detta strukturellt: nästa testcykel verifierar automatiskt om tidigare brister har åtgärdats. Det skapar ansvarighet.

Opsios SOC-team ser regelbundet att brister som rapporterats i ett pentest fortfarande finns kvar vid nästa test. Med en återkommande process blir det synligt – och svårt att ignorera.

Molnspecifika utmaningar vid pentest

Organisationer som kör sin infrastruktur i AWS, Azure eller Google Cloud möter attackytor som skiljer sig markant från traditionella datacenter. Molnmigrering skapar nya kategorier av brister som kräver specialiserade testmetoder:

IAM-felkonfigurationer är den enskilt vanligaste molnbristen vi stöter på. En överprivilegierad roll i AWS eu-north-1 (Stockholm) kan ge en angripare tillgång till hela organisationens data, oavsett hur stark den övriga säkerheten är.

Exponerade lagringslösningar – S3-buckets och Azure Blob Storage med felaktig åtkomstkontroll dyker upp med förvånande regelbundenhet, även hos organisationer som anser sig vara mogna.

Nätverkssegmentering i molnet fungerar annorlunda än i ett fysiskt datacenter. Security Groups och NACLs i AWS, eller NSG:er i Azure Sweden Central, kräver pentest-team som förstår molnens nätverksmodell.

Container- och Kubernetes-säkerhet – organisationer som kör arbetsbelastningar i EKS, AKS eller GKE behöver testa container escape-scenarier, pod security policies och RBAC-konfigurationer. Enligt CNCF Annual Survey har Kubernetes-adoption nått en mognad där säkerhetstestning av orkestreringsskiktet inte längre är valfritt.

En viktig detalj: både AWS och Azure tillåter penetrationstest mot era egna resurser utan förhandsanmälan för de flesta tjänster. Undantagen är i regel DNS-zonvandringsattacker och DDoS-simulering. Kontrollera alltid aktuell policy innan teststart.

Frekvens: hur ofta är tillräckligt?

"Årligen" är ett minimum, inte ett mål. Rätt frekvens beror på er förändringstakt och riskprofil:

• Årligt fullskaligt pentest – baslinjen som de flesta ramverk kräver
• Kvartalsvis testning – rekommenderat för organisationer med hög förändringstakt, t.ex. de som kör CI/CD-pipelines med managerad DevOps
• Testning vid väsentliga förändringar – ny applikation, stor infrastrukturändring, ny integration mot tredjepartstjänst
• Kontinuerlig testning – automatiserade skanningar som körs löpande, kompletterade med manuella pentest vid definierade intervall

Automatisering kontra manuell testning

Automatiserade verktyg (Nessus, Qualys, Burp Suite Pro, Nuclei) är utmärkta för att fånga kända sårbarheter och hålla koll på konfigurationsdrift mellan manuella tester. Men de ersätter inte manuellt pentest. En automatiserad skanner hittar en SQL-injection – en erfaren testare hittar den logiska bristen i affärsflödet som låter dig godkänna din egen kreditansökan.

Bästa praxis är att kombinera:

1. Löpande automatiserad skanning (veckovis eller dagligen i CI/CD)

2. Kvartalsvisa fokuserade tester mot kritiska applikationer

3. Årligt fullskaligt pentest som täcker hela attack-ytan

FinOps-perspektivet: vad kostar det att inte testa?

Säkerhetstestning uppfattas ofta som en kostnad. Det perspektivet vänds snabbt om man jämför med alternativet. Enligt IBM:s Cost of a Data Breach Report har genomsnittskostnaden för ett dataintrång konsekvent legat på miljontals dollar globalt – och den nordiska siffran är inte lägre. Lägger man till GDPR-sanktioner (IMY har utdömt böter upp till tiotals miljoner kronor), driftstopp och reputationsskada, blir bilden tydlig.

Ett återkommande pentest-program för en medelstor organisation kostar typiskt 150 000–500 000 SEK per år beroende på scope. Det är en bråkdel av kostnaden för en enda allvarlig incident.

Från ett Cloud FinOps-perspektiv bör säkerhetstestning behandlas som en operativ driftkostnad, inte som ett projekt. Budgetera det löpande och koppla det till er riskaptit.

Att välja pentest-partner: vad ni bör kräva

Inte alla pentest-leverantörer levererar samma värde. Här är vad vi rekommenderar att ni utvärderar:

Certifieringar – OSCP, OSCE, CREST eller likvärdigt. Certifieringar garanterar inte kvalitet, men de filtrerar bort de som saknar grundläggande kompetens.

Branschförståelse – en testare som förstår er verksamhet hittar brister som en generalist missar. Fintech kräver annan expertis än tillverkningsindustri.

Molnkompetens – om ni kör i AWS, Azure eller multi-cloud behöver teamet praktisk erfarenhet av molnspecifika attacktekniker, inte bara traditionellt nätverkspentest.

Åtgärdsstöd – den bästa pentestern förklarar inte bara vad som är fel, utan ger konkreta rekommendationer som era team faktiskt kan implementera.

Kontinuitet – en partner som lär känna er miljö över tid ger mer värde än en ny leverantör varje år. De ser mönster, förstår er arkitektur och kan bedöma mognadsutvecklingen.

Så kommer ni igång med ett återkommande program

1. Inventera er attackyta – vilka system, applikationer, API:er och molnresurser behöver testas?

2. Prioritera baserat på risk – börja med det som har högst affärspåverkan

3. Definiera frekvens – årligt pentest som minimum, kvartalsvis för kritiska system

4. Välj testtyper – anpassa black/grey/white box efter systemkategori

5. Integrera med er säkerhetsprocess – pentestresultat ska mata in i er riskhantering, inte existera i isolation

6. Mät och förbättra – spåra antal fynd, åtgärdstid och återkommande brister mellan testcykler

Opsios managerade molntjänster inkluderar stöd för att bygga en sammanhållen säkerhetsprocess där pentest-resultat kopplas direkt till åtgärdsarbete och kontinuerlig övervakning via vårt 24/7 SOC/NOC.

Vanliga frågor

Hur ofta bör vi genomföra penetrationstest?

Minst årligen enligt de flesta ramverk (ISO 27001, NIS2), men kvartalsvis eller efter större förändringar i infrastrukturen ger betydligt bättre skydd. Frekvensen bör styras av riskprofil, förändringstakt och regulatoriska krav.

Vad är skillnaden mellan sårbarhetsskanning och pentest?

Sårbarhetsskanning är automatiserad och identifierar kända brister. Ett penetrationstest utförs manuellt av säkerhetsexperter som faktiskt försöker exploatera sårbarheterna, kedja dem samman och visa verklig affärspåverkan – precis som en riktig angripare.

Uppfyller årliga pentest NIS2-direktivets krav?

NIS2 kräver systematisk säkerhetsutvärdering och riskhantering. Årliga pentest är en central del av detta, men direktivet kräver också löpande riskbedömning, incidenthantering och supply chain-säkerhet. Pentest ensamt räcker inte.

Vad kostar ett återkommande pentest-program?

Kostnaden beror på scopets storlek, testtyp och frekvens. Typiskt ligger ett årligt program för en medelstor organisation på 150 000–500 000 SEK. Jämför det med genomsnittskostnaden för ett dataintrång – då framstår investeringen som blygsam.

Kan vi göra pentest mot vår molninfrastruktur i AWS eller Azure?

Ja, men det kräver att testteamet förstår molnspecifika attackytor som IAM-felkonfigurationer, exponerade S3-buckets och överprivilegierade roller. Både AWS och Azure tillåter pentest mot egna resurser utan förhandsanmälan, med vissa undantag för DDoS-simulering och DNS-attacker.