Rapportens grundstruktur: de fem centrala delarna

En professionell penetrationstestrapport följer en beprövad struktur. Avvikelser förekommer beroende på uppdragets karaktär, men dessa fem delar ska alltid finnas med.

1. Sammanfattning för ledningen (Executive Summary)

Det här avsnittet är den viktigaste delen av rapporten för beslutsfattare — och den del som oftast skrivs slarvigt. En bra sammanfattning för ledningen ska:

• Förklara testets omfattning i affärstermer, inte teknisk jargong
• Ge en övergripande riskbild: hur exponerad är organisationen?
• Kvantifiera fynden i kategorier (kritisk, hög, medel, låg)
• Lyfta fram de 3–5 mest affärskritiska fynden med tydlig konsekvens
• Ge en rekommenderad prioriteringsordning

Sammanfattningen bör inte överstiga 2–3 sidor. En VD som läser den ska förstå riskläget och vad det kostar att inte agera — utan att behöva dechiffrera tekniska akronymer.

2. Testomfattning och metodbeskrivning

Transparens kring vad som testades, hur och under vilka förutsättningar är avgörande för rapportens trovärdighet. Avsnittet ska specificera:

• Testtyp: black-box, grey-box eller white-box
• Scope: IP-adressomfång, domäner, applikationer, fysiska lokaler
• Undantag: system som exkluderats och varför
• Tidsperiod: exakta datum och tider (viktigt för loggkorrelation)
• Metodik: OWASP Testing Guide, PTES, NIST SP 800-115 eller liknande ramverk
• Verktyg: vilka automatiserade och manuella verktyg som användes
• Begränsningar: eventuella hinder som påverkade testresultaten

Det här avsnittet skyddar både uppdragsgivaren och testaren. Om en sårbarhet missas för att ett system var utanför scope, ska det framgå tydligt här.

3. Detaljerade fynd med CVSS-klassificering

Varje identifierad sårbarhet dokumenteras som ett eget fynd med en standardiserad struktur:

Exempelstruktur för ett enskilt fynd:

```

Fynd-ID: PT-2026-042

Titel: SQL Injection i inloggningsformulär

CVSS 4.0-poäng: 9.1 (Kritisk)

Påverkat system: app.example.se — inloggningsmodul

Beskrivning: Inmatningsfältet för användarnamn saniterar inte

SQL-specialtecken, vilket möjliggör databasåtkomst.

Bevis (PoC): [skärmdump + kommando som visar databasuttag]

Affärspåverkan: En angripare kan extrahera hela kunddatabasen

inkl. personuppgifter — GDPR-incident.

Åtgärd: Implementera parameteriserade frågor (prepared

statements). Validera all inmatning server-side.

Prioritet: Omedelbar — åtgärda inom 48 timmar.

```

CVSS (Common Vulnerability Scoring System) version 4.0, som är standard sedan 2024, ger en nyanserad poängsättning som tar hänsyn till angreppsvektor, komplexitet, påverkan och kontextuella faktorer. Poängen grupperas enligt:

4. Riskmatris och prioriteringsmodell

Riskmatrisen är det verktyg som omvandlar tekniska fynd till affärsriskbedömningar. Den kombinerar sannolikheten att en sårbarhet utnyttjas med konsekvensen om det sker.

En typisk riskmatris i pentestrapporten kan se ut så här:

Sannolikheten bedöms utifrån faktorer som: är sårbarheten publikt känd? Krävs autentisering? Finns exploits tillgängliga? Konsekvensen bedöms utifrån affärspåverkan: driftstopp, dataintrång, regulatoriska böter, varumärkesskada.

Vi på Opsio ser ofta att organisationer fastnar i att åtgärda "lätta" medelsårbarheter och skjuter upp de kritiska som kräver mer arbete. Riskmatrisen motverkar det genom att synliggöra var den verkliga risken finns.

5. Åtgärdsplan med tidsramar och ansvariga

Den avslutande delen — och den som avgör om rapporten faktiskt leder till förbättring — är åtgärdsplanen. Varje fynd kopplas till:

• Specifik åtgärd: inte "förbättra säkerheten" utan "uppgradera Apache till version X.Y.Z och aktivera mod_security med OWASP CRS"
• Ansvarig person eller team: namngivet
• Tidsfrist: baserad på allvarlighetsgrad
• Verifieringsmetod: hur bekräftar man att åtgärden genomförts korrekt?
• Status-spårning: öppet → pågående → verifierat → stängt

Penetrationstest och regelefterlevnad

NIS2-direktivet

NIS2-direktivet, som trädde i kraft i EU under 2024–2025, ställer explicita krav på att organisationer inom väsentliga och viktiga sektorer genomför riskbedömningar och testar sin cybersäkerhet. Penetrationstest nämns inte ordagrant, men de utgör i praktiken det mest effektiva sättet att uppfylla direktivets krav på regelbunden utvärdering av säkerhetsåtgärder.

En välstrukturerad pentestrapport fungerar som direkt bevisföring vid tillsyn och granskning av Integritetsskyddsmyndigheten (IMY) eller sektorsspecifika tillsynsmyndigheter. NIS2-anpassad molnsäkerhet

ISO 27001

ISO 27001 (Annex A, kontroll A.8.8) kräver hantering av tekniska sårbarheter. Penetrationstest och tillhörande rapportering är standardmetoden för att visa att denna kontroll efterlevs. Certifieringsrevisorer förväntar sig att se pentestrapporter som en del av organisationens informationssäkerhetshantering.

GDPR

Om penetrationstestet identifierar sårbarheter som kan leda till läckage av personuppgifter, aktiveras GDPR:s krav direkt. Rapporten bör tydligt flagga fynd med GDPR-relevans och beskriva potentiell påverkan i termer av berörd datakategori och uppskattad volym av registrerade.

Vanliga misstag vi ser i pentestrapporten

Opsios SOC-team granskar regelbundet pentestrapporten som våra kunder tar emot från olika leverantörer. De vanligaste bristerna:

Ingen affärskontext. Fynd listas med tekniska detaljer men utan koppling till verksamhetsrisk. En XSS-sårbarhet i en intern testmiljö och en XSS-sårbarhet i en kundportal med betalningsuppgifter har helt olika affärspåverkan — men de presenteras identiskt.

Skannerrapport = pentestrapport. En Nessus- eller Qualys-rapport som exporterats rakt av är inte en pentestrapport. Automatiserade verktyg producerar brus, falsklarm och missar logikfel. Professionell analys, validering och kontextualisering är det som gör ett pentest värdefullt.

Inga bevis. Utan proof-of-concept (PoC) och skärmdumpar saknar rapporten trovärdighet. Varje kritiskt och högt fynd ska backas upp med bevis som visar att sårbarheten verkligen kan utnyttjas — inte bara att den potentiellt existerar.

Generiska åtgärdsförslag. "Uppdatera programvaran" hjälper ingen. Åtgärderna ska vara specifika för den testade miljön och inkludera versionsnummer, konfigurationsändringar och valideringssteg.

Ingen uppföljning. Rapporten levereras, bokmärks och glöms. Vi rekommenderar att åtgärdsstatusen rapporteras till ledningen månadsvis och att ett verifieringstest genomförs inom 90 dagar efter att kritiska åtgärder implementerats.

Molnspecifika utmaningar i pentestrapporten

Allt fler organisationer kör sin infrastruktur i AWS, Azure eller Google Cloud — och det påverkar hur penetrationstest genomförs och rapporteras. Managerade molntjänster

Ansvarsgränser. Molnleverantörernas shared responsibility-modell innebär att penetrationstestets scope måste vara tydligt avgränsat. AWS tillåter exempelvis pentest av kundens egna resurser men inte av underliggande infrastruktur. Rapporten ska redogöra för vilka lager som testats och vilka som ligger utanför kundens kontroll.

IAM-konfigurationer. I Opsios SOC ser vi att felkonfigurerade IAM-policyer (Identity and Access Management) är bland de vanligaste kritiska fynden i molnmiljöer. Överprivilegierade roller, avsaknad av MFA för administrativa konton och exponerade API-nycklar dyker upp i rapport efter rapport.

Publikt exponerade resurser. S3-hinkar med felaktig åtkomstpolicy, öppna säkerhetsgrupper och exponerade databaser — det här är lågt hängande frukt som automatiserade skanningar hittar, men som ändå kvarstår i förvånansvärt många produktionsmiljöer. Rapporten ska specifikt adressera molnkonfigurationsbrister, inte bara traditionella nätverks- och applikationssårbarheter.

Regionspecifika överväganden. För organisationer med verksamhet i Sverige och EU bör rapporten beakta var data lagras. Test av resurser i eu-north-1 (Stockholm) eller Sweden Central kan ha andra regulatoriska implikationer än globalt distribuerade miljöer. Cloud FinOps och kostnadsoptimering

Från rapport till säkerhetsförbättring: ett praktiskt ramverk

En pentestrapport har inget egenvärde om den inte leder till faktisk förändring. Vi rekommenderar följande process:

1. Ledningspresentation (dag 1–3): Sammanfattning för ledningen presenteras. Beslut om budget och prioritering fattas.

2. Teknisk genomgång (dag 3–5): Detaljerade fynd gås igenom med berörda IT-team. Åtgärder fördelas och tidsplan fastställs.

3. Åtgärdsfas (dag 5–90): Kritiska fynd åtgärdas omedelbart. Höga inom en vecka. Medel och låga enligt plan.

4. Verifieringstest (dag 60–90): Ett begränsat re-test genomförs för att verifiera att kritiska och höga fynd har åtgärdats korrekt.

5. Statusrapportering: Månatlig uppföljning till ledningen tills alla fynd är stängda eller medvetet accepterade med dokumenterad riskacceptans.

Managerad DevOps och säkerhet

Checklista: vad en bra pentestrapport ska innehålla

Vanliga frågor

Hur ofta bör ett penetrationstest genomföras?

Som minimum årligen, men vid väsentliga förändringar i infrastruktur, applikationer eller efter säkerhetsincidenter bör ytterligare tester planeras. NIS2-direktivet och ISO 27001 förutsätter regelbunden testning — i praktiken innebär det att organisationer med hög riskexponering testar kvartalsvis eller oftare.

Vad skiljer en intern pentestrapport från en rapport för extern revision?

Den interna rapporten fokuserar på tekniska detaljer och åtgärdssteg för IT-teamet. En revisionsrapport betonar istället efterlevnad, riskbedömning och koppling till ramverk som ISO 27001 eller NIS2. I praktiken behöver de flesta organisationer båda perspektiven i samma dokument, strukturerat med en sammanfattning för ledningen och tekniska bilagor.

Vad är CVSS och varför används det i pentestrapporten?

CVSS (Common Vulnerability Scoring System) är ett standardiserat poängsystem för att bedöma allvarlighetsgraden hos sårbarheter på en skala 0–10. Det gör det möjligt att jämföra och prioritera fynd objektivt, oavsett vilken typ av sårbarhet det handlar om. Version 4.0 används sedan 2024 och ger mer nyanserad kontextbedömning.

Räcker det att använda automatiska skanningsverktyg istället för manuella penetrationstest?

Nej. Automatiska verktyg hittar kända sårbarheter men missar affärslogikfel, kedjeangrepp och kontextberoende svagheter. Professionella penetrationstest kombinerar automatiserade skanningar med manuella tester där erfarna säkerhetsspecialister tänker som en angripare — det är kombinationen som ger verkligt värde.

Hur hanteras känsliga fynd i penetrationstestrapporten?

Rapporten ska klassificeras som konfidentiell och distribueras enbart till namngivna mottagare. Detaljerade exploateringsbevis bör placeras i krypterade bilagor, inte i huvuddokumentet. Vi rekommenderar att rapporten versionshanteras och att åtkomst loggas — särskilt om den innehåller bevis på att kritiska system kunnat komprometteras.