Scopning: där de flesta gör fel

Det vanligaste misstaget vi ser hos organisationer som förbereder sig för ISO 27001 är att de beställer ett "standard penetrationstest" utan att koppla scopet till sitt ISMS (Information Security Management System). Resultatet blir en rapport med fynd som inte mappar mot deras kontroller och en revisor som ställer frågor de inte kan svara på.

Utgå från er SoA

Er Statement of Applicability (SoA) listar vilka kontroller från Annex A ni har valt att implementera och varför. Pentest-scopet ska verifiera att de tekniska kontrollerna i SoA:n fungerar. Om ni har valt bort en kontroll med en dokumenterad motivering behöver ni inte testa den – men ni behöver kunna förklara varför.

Definiera testytor systematiskt

Ett typiskt scope för en organisation med hybridinfrastruktur ser ut så här:

Externt nätverkstest:

• Publika IP-adresser och DNS-zoner
• Exponerade tjänster (webb, VPN, e-post, API:er)
• TLS/SSL-konfiguration
• Exponering i molnresurser (S3-buckets, Azure Blob Storage, etc.)

Internt nätverkstest:

• Active Directory-säkerhet (Kerberoasting, Pass-the-Hash, delegering)
• Nätverkssegmentering och brandväggsregler
• Lateral movement-möjligheter
• Privilegierade konton och service accounts

Webbapplikationstest:

• OWASP Top 10 (2021-versionen fortfarande relevant)
• Autentisering och sessionshantering
• Behörighetseskalering
• API-säkerhet

Molnkonfiguration:

• IAM-policyer och rollkedja
• Nätverkskonfiguration (Security Groups, NACLs, NSGs)
• Lagrings- och databaskonfiguration
• Loggning och övervakning

Molnsäkerhet

Välj rätt testmetod

Vår rekommendation: grey box för de flesta ISO 27001-tester. Ni ger testaren samma åtkomstnivå som en komprometterad anställd eller en angripare som tagit sig förbi perimetern – det scenariot är det relevanta 2026.

Tidslinje: när i certifieringsprocessen ska pentestet ske?

Timing är avgörande. Vi ser tre vanliga misstag:

1. Pentest för tidigt – ni testar innan kontrollerna är implementerade, och testet visar bara att ni inte är redo ännu (det visste ni redan).

2. Pentest för sent – ni kör testet veckan innan steg 2-revisionen och har ingen tid att åtgärda fynden.

3. Ingen re-test – ni åtgärdar fynden men verifierar aldrig att åtgärderna faktiskt fungerar.

Rekommenderad tidslinje

```

Månad 1–6: ISMS-uppbyggnad, riskbedömning, kontrollimplementering

Månad 7–8: Penetrationstest (första omgången)

Månad 8–9: Åtgärder baserat på pentest-fynd

Månad 9–10: Re-test / verifiering av åtgärder

Månad 10: Intern revision (klausul 9.2)

Månad 11: Ledningens genomgång (klausul 9.3)

Månad 12: Steg 1-revision (dokumentgranskning)

Månad 13–14: Steg 2-revision (implementeringsgranskning)

```

Ge er själva minst 4–6 veckor mellan pentest-rapport och certifieringsrevision. Kritiska fynd kräver tid att åtgärda ordentligt – inte bara lappa med en snabbfix.

Vad revisorn faktiskt vill se

Certifieringsrevisorer är inte intresserade av att läsa 200 sidor sårbarhetsskanning från Nessus. De vill se bevis för en fungerande process:

1. Att ni valt pentest-scope baserat på riskbedömningen

Koppla scope-dokumentet till er riskregister och SoA. Visa att ni testat det som spelar roll.

2. Att testaren är kompetent och oberoende

Intern personal som testar sina egna system räcker inte. Revisorn förväntar sig en oberoende part, helst med erkänd certifiering (OSCP, CREST, CHECK eller liknande).

3. Att fynd hanteras i er riskbehandlingsprocess

Varje sårbarhet som pentestet identifierar ska loggas, riskbedömas och antingen åtgärdas, accepteras (med ledningens godkännande) eller mitigeras. Visa spårbarheten – från fynd till åtgärd till verifiering.

4. Att ni kan visa förbättring

Om ni har tidigare pentest-rapporter, visa trenden. Revisorer älskar att se att antalet kritiska fynd minskar över tid.

NIS2-direktivet: ytterligare krav på teknisk testning

Sedan NIS2-direktivet trädde i kraft har organisationer inom väsentliga och viktiga sektorer (energi, transport, hälsa, digital infrastruktur m.fl.) ytterligare krav på teknisk säkerhetstestning. Artikel 21 specificerar att lämpliga och proportionella tekniska åtgärder ska vidtas, inklusive "policyer och förfaranden för att bedöma effektiviteten av åtgärder för hantering av cybersäkerhetsrisker."

Penetrationstest uppfyller detta krav direkt. Organisationer som redan förbereder sig för ISO 27001 har en naturlig fördel – ramverket överlappar till stor del med NIS2:s krav. Men observera: NIS2 har bredare scope och inkluderar exempelvis leveranskedjesäkerhet (supply chain) och incidentrapportering som ISO 27001 inte täcker lika explicit.

Managerade molntjänster

Vanliga fynd vi ser vid pentest inför ISO 27001

Från Opsios SOC/NOC-team och de pentester vi stödjer ser vi återkommande mönster hos organisationer som förbereder sig för certifiering:

Identitets- och åtkomsthantering

• Service accounts med domänadministratörsrättigheter som "alltid funnits"
• Avsaknad av MFA på VPN och administrativa gränssnitt
• Överbreda IAM-roller i AWS/Azure som ger mer åtkomst än vad som behövs

Nätverkssegmentering

• Platt nätverk där en komprometterad arbetsstation kan nå produktionsdatabaser direkt
• Brandväggsregler som öppnats "tillfälligt" för år sedan och aldrig stängts
• Otillräcklig mikrosegmentering i Kubernetes-kluster

Patchhantering

• Kritiska CVE:er som varit kända i månader men inte åtgärdats
• Testmiljöer med äldre mjukvaruversioner som är nåbara från internet
• Tredjepartsbibliotek i webbapplikationer som inte uppdateras

Loggning och övervakning

• Loggar som samlas in men aldrig granskas
• Otillräcklig retention – loggar som raderas efter 30 dagar trots att incidentutredningar kräver längre historik
• Blindfläckar i molnmiljöer där CloudTrail eller Azure Activity Log inte är aktiverat fullt ut

Managerad DevOps

Att välja rätt pentest-leverantör

Alla penetrationstestare är inte likvärdiga. Inför en ISO 27001-certifiering är det viktigt att välja en leverantör som förstår compliance-kontexten, inte bara de tekniska aspekterna.

Frågor att ställa:

• Kan ni mappa fynd mot specifika Annex A-kontroller?
• Levererar ni en executive summary som vår ledning kan förstå?
• Inkluderar ni rekommendationer prioriterade efter risk, inte bara CVSS-poäng?
• Erbjuder ni re-test av åtgärdade fynd?
• Vilka certifieringar har era testare? (OSCP, OSCE, CREST, CEH som minimum)

Varningssignaler:

• Leverantörer som enbart kör automatiserade verktyg och kallar det penetrationstest
• Rapporter som är genererade direkt från verktyg utan manuell analys
• Oförmåga att förklara skillnaden mellan sårbarhetsskanning och penetrationstest
• Inga tydliga Rules of Engagement före teststart

Från pentest-rapport till åtgärd: processen som spelar roll

Rapporten i sig har inget värde om den inte leder till förändring. Så här strukturerar vi åtgärdsprocessen hos våra kunder:

Steg 1: Triage (dag 1–3 efter rapport)

Gå igenom samtliga fynd med pentest-teamet. Prioritera utifrån affärsrisk, inte bara teknisk allvarlighetsgrad. En medium-sårbarhet i er betalningsplattform kan vara viktigare än en hög-sårbarhet i en intern testmiljö.

Steg 2: Åtgärdsplan (vecka 1)

Tilldela varje fynd en ägare, en deadline och en verifieringsmetod. Logga detta i ert riskregister – det är precis vad revisorn vill se.

Steg 3: Implementering (vecka 2–6)

Genomför åtgärder. Dokumentera vad som gjorts och varför. Om ni väljer att acceptera en risk istället för att åtgärda den – dokumentera ledningens beslut formellt.

Steg 4: Re-test (vecka 6–8)

Låt pentest-leverantören verifiera att åtgärderna fungerar. Denna re-test-rapport är guld vid certifieringsrevisionen.

Cloud FinOps

Kostnad vs. värde: ett driftsperspektiv

Penetrationstest inför ISO 27001 är inte en kostnad – det är en investering i att undvika mycket dyrare problem. En avvikelse vid certifieringsrevisionen kostar tid, pengar och trovärdighet. Ett dataintrång kostar avsevärt mer.

Flexeras State of the Cloud har konsekvent visat att kostnadshantering är den största utmaningen i molnmiljöer. Samma princip gäller säkerhet: det billigaste alternativet (hoppa över pentest) blir det dyraste på sikt.

Räkna inte bara med kostnaden för själva testet. Räkna med tiden för åtgärder, re-test, dokumentation och intern kommunikation. En realistisk budget för en medelstor organisation med hybridinfrastruktur är 150 000–400 000 SEK totalt, inklusive re-test.

Vanliga frågor

Är penetrationstest obligatoriskt för ISO 27001-certifiering?

Inte ordagrant i standarden, men Annex A kontroll A.8.8 (hantering av tekniska sårbarheter) och A.5.36 (efterlevnad av policyer och standarder) förutsätter att ni kan bevisa att era kontroller fungerar. Penetrationstest är den mest trovärdiga metoden, och de flesta certifieringsorgan förväntar sig det i praktiken.

Hur ofta bör vi genomföra penetrationstest?

Minst årligen och efter väsentliga förändringar i infrastruktur eller applikationer. Många organisationer kör även kvartalsvis automatiserad sårbarhetsskanning som komplement till manuella tester.

Vad kostar ett penetrationstest inför ISO 27001?

Det beror helt på scope. Ett test mot en enskild webbapplikation kan kosta 50 000–100 000 SEK, medan ett komplett internt och externt test med AD-granskning, molninfrastruktur och social engineering kan landa på 250 000–500 000 SEK. Avgörande är att scopet matchar er SoA.

Vilken typ av penetrationstest behövs?

Det vanligaste är en kombination av externt nätverkstest, internt nätverkstest och webbapplikationstest. Om ni kör arbetsbelastningar i AWS, Azure eller GCP bör molnkonfigurationsgranskning ingå. Vilken mix som krävs styrs av er riskbedömning och SoA.

Kan vi använda automatiska verktyg istället för manuellt pentest?

Automatiserad sårbarhetsskanning (Nessus, Qualys, etc.) är ett utmärkt komplement men ersätter inte manuellt penetrationstest. Automatiserade verktyg missar logikfel, kedjeangrepp och kontextberoende sårbarheter som en erfaren testare hittar.

---

Penetrationstest inför ISO 27001 handlar inte om att bocka av en ruta. Det handlar om att ta reda på om era säkerhetskontroller håller när någon faktiskt försöker ta sig igenom dem. Organisationer som behandlar pentest som en formell övning får en rapport som samlar damm. Organisationer som behandlar det som en del av sitt kontinuerliga säkerhetsarbete får ett ISMS som faktiskt skyddar verksamheten – och en certifiering som betyder något.

Molnmigrering