Penetrationstest kostnad 2026: priser, faktorer och rätt investering
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Penetrationstest kostnad 2026: priser, faktorer och rätt investering
Ett penetrationstest kostar i Sverige typiskt mellan 40 000 och 500 000 SEK, beroende på om ni testar en enskild webbapplikation eller en komplex hybridmiljö med hundratals tjänster. Med NIS2-direktivets ikraftträdande och en hotbild där ransomware-attacker mot svenska organisationer ökar i både frekvens och sofistikering, är frågan inte längre om ni bör testa — utan hur ni investerar rätt i testning som faktiskt gör skillnad.
Viktiga slutsatser
- Ett penetrationstest kostar typiskt 40 000–500 000 SEK beroende på omfattning, komplexitet och testtyp
- NIS2-direktivet gör regelbunden säkerhetstestning till en praktisk nödvändighet för svenska organisationer
- Manuell expertanalys kostar mer än automatiserade skanningar — men hittar de sårbarheter som faktiskt utnyttjas vid riktade angrepp
- Att inte testa är dyrare: en enda allvarlig incident kan kosta mångfalt mer än årlig säkerhetstestning
Vad ett penetrationstest faktiskt innebär
Ett penetrationstest är en kontrollerad attack mot era egna system, utförd av säkerhetsexperter som använder samma tekniker som verkliga angripare. Syftet är att hitta och bevisa exploaterbara sårbarheter innan någon annan gör det.
Det skiljer sig fundamentalt från en sårbarhetsskanning. En skanning kör automatiserade verktyg mot era system och listar kända brister. Ett pentest går vidare: testaren försöker aktivt exploatera sårbarheterna, kedja ihop flera svagheter och eskalera sin åtkomst — precis som vid en riktig attack. Det är skillnaden mellan att veta att dörren kan vara olåst och att faktiskt öppna den, gå in och visa vad som hade hänt.
I Opsios SOC ser vi dagligen hur automatiserade skanningar missar affärslogikfel, komplexa attackkedjor och konfigurationsbrister som bara syns i samspelet mellan tjänster. En AWS-miljö kan ha perfekt SecurityHub-poäng och ändå vara sårbar genom en felkonfigurerad IAM-roll som ger lateral rörelse från en komprometterad Lambda-funktion till produktionsdatabasen. Den typen av brister kräver en människa med angriparperspektiv.
Testprocessens faser
Ett professionellt penetrationstest följer en etablerad metodik, vanligen baserad på OWASP Testing Guide, PTES eller OSSTMM:
1. Scope-definition och avtal — vilka system, vilka metoder, vilka begränsningar
2. Rekognosering — kartläggning av er digitala exponering och attackyta
3. Sårbarhetsdetektion — kombinerad automatiserad och manuell analys
4. Exploatering — kontrollerade försök att utnyttja identifierade svagheter
5. Post-exploitation — lateral rörelse, privilegieeskalering, dataexfiltration
6. Rapportering — detaljerad dokumentation med riskklassning och åtgärdsförslag
Vill ni ha expertstöd med penetrationstest kostnad 2026?
Våra molnarkitekter hjälper er med penetrationstest kostnad 2026 — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
Kostnadsfaktorer: vad som styr priset
Prisspannet för pentester är brett, och det finns goda skäl till det. Att förstå vad som driver kostnaden hjälper er att specificera rätt scope och undvika både under- och övertestning.
Omfattning och komplexitet
Den enskilt största kostnadsdrivaren. Att testa en webbapplikation med fem endpoints är fundamentalt annorlunda från att testa en hybridmiljö med AWS-konton, on-prem-servrar, VPN-tunnlar och hundra mikrotjänster.
| Testtyp | Typiskt prisintervall (SEK) | Tidsåtgång | Passar för |
|---|---|---|---|
| Extern nätverksskanning (automatiserad) | 10 000–30 000 | 1–2 dagar | Baslinjeöversikt, compliance-minimum |
| Webbapplikationstest (manuellt) | 50 000–150 000 | 3–7 dagar | Enskild app med autentisering och affärslogik |
| Extern infrastrukturtest | 60 000–200 000 | 5–10 dagar | Perimetersäkerhet, exponerade tjänster |
| Intern nätverkstest | 80 000–250 000 | 5–10 dagar | Lateral rörelse, Active Directory-attacker |
| Molnmiljötest (AWS/Azure/GCP) | 100 000–300 000 | 5–15 dagar | IAM-konfigurationer, tjänsteinteraktioner, dataskydd |
| Red team-övning (fullskalig) | 200 000–500 000+ | 2–6 veckor | Realistisk hotsimulerning med social engineering och fysisk åtkomst |
Testmetodik: black box, grey box, white box
- Black box — testaren har ingen förhandsinformation. Simulerar en extern angripare. Tar längre tid men testar detektionsförmågan.
- Grey box — testaren får viss information (t.ex. API-dokumentation, nätverksdiagram). Mest kostnadseffektiv för de flesta organisationer.
- White box — testaren har full tillgång till källkod och arkitekturdokumentation. Hittar mest, men kräver att testaren hanterar stora mängder information.
Vår erfarenhet på Opsio är att grey box ger bäst avkastning per investerad krona. Testaren slipper lägga dagar på rekognosering som inte tillför säkerhetsvärde, och kan fokusera tiden på att exploatera de verkligt kritiska attackytorna.
Leverantörens kompetens och certifieringar
En junior testare med OSCP kostar mindre per timme än ett team med OSCE3, CREST- och SANS-certifieringar — men hittar också färre av de sårbarheter som faktiskt utnyttjas vid riktade attacker. Billigaste offerten är sällan den mest kostnadseffektiva.
Fråga potentiella leverantörer:
- Vilka certifieringar har testarna (inte företaget, utan de faktiska personerna)?
- Hur stor andel av testtiden är manuell analys kontra automatiserad skanning?
- Kan de visa exempelrapporter (anonymiserade)?
- Har de erfarenhet av er specifika molnplattform och bransch?
Molnspecifika aspekter: AWS, Azure och GCP
Att testa en molnmiljö skiljer sig väsentligt från traditionell nätverkstestning. Attackytan inkluderar IAM-policies, tjänstekonfigurationer, nätverkssegmentering i VPC:er, secrets management och CI/CD-pipelines — utöver de klassiska nätverks- och applikationstesterna.
AWS-specifika testområden
I eu-north-1 (Stockholm) ser vi i Opsios SOC återkommande konfigurationsbrister: S3-hinkar med för breda policies, IAM-roller med *-permissions som ärvts från utvecklingsmiljöer, och Security Groups som öppnats tillfälligt men aldrig stängts. AWS tillåter pentester mot de flesta tjänster utan förhandsgodkännande (se AWS Penetration Testing Policy), men Red Team-övningar kräver fortfarande granskning.
Azure-specifika testområden
I Sweden Central är Azure AD (nu Entra ID) det vanligaste testobjektet. Felkonfigurerade Conditional Access-policies och överdrivna appregistreringsrättigheter är vanligare än man tror. Azure kräver inget formellt godkännande för standardpentester, men DDoS-testning kräver anmälan.
Molnpentester kostar generellt 20–40 % mer än motsvarande test av traditionell infrastruktur. Det beror på att testarna behöver djup plattformskunskap och att attackytorna ofta är bredare och mer abstrakta.
NIS2 och regulatoriska krav: vad lagen faktiskt kräver
NIS2-direktivet kräver inte uttryckligen penetrationstest — det kräver att organisationer vidtar "lämpliga och proportionella tekniska, operativa och organisatoriska åtgärder" för att hantera risker. I praktiken innebär det att tillsynsmyndigheten förväntar sig att ni kan visa att ni testat era system mot realistiska hot.
Enligt NIS2 artikel 21 ska åtgärderna inkludera bland annat:
- Riskanalys och säkerhetspolicies
- Incidenthantering
- Driftskontinuitet och krishantering
- Säkerhet i leveranskedjan
- Testning och revision av säkerhetsåtgärder
Den sista punkten är den som direkt berör pentester. Organisationer som klassificeras som "väsentliga" (essential) eller "viktiga" (important) entiteter behöver visa att de har en systematisk process för att testa sina säkerhetskontroller.
Sanktionsavgifterna under NIS2 kan uppgå till 10 miljoner euro eller 2 % av global årsomsättning för väsentliga entiteter. Ett årligt penetrationstest på 100 000–300 000 SEK framstår som en rimlig investering i det perspektivet.
DORA (Digital Operational Resilience Act) ställer ännu hårdare krav på finanssektorn: obligatorisk TLPT (Threat-Led Penetration Testing) vart tredje år, utförd av oberoende testare.
Så beräknar ni rätt budget: ett ramverk
Istället för att fråga "vad kostar ett pentest?" bör ni fråga "vad är vår attackyta och vad är konsekvensen av ett intrång?" Här är ett praktiskt ramverk:
Steg 1: Kartlägg kritiska tillgångar
Vilka system, applikationer och data är affärskritiska? Vad skulle det kosta om de komprometterades — i driftstopp, regulatoriska sanktioner, kundförlust och renommé?
Steg 2: Definiera testscope baserat på risk
Inte allt behöver testas varje år. Prioritera:
- Årligen: kundnära applikationer, autentiseringssystem, molninfrastruktur
- Vid förändringar: nya tjänster, arkitekturförändringar, migreringar
- Vart 2–3 år: interna nätverk som förändras sällan, fysisk säkerhet
Steg 3: Räkna totalkostnad, inte bara testpris
Den verkliga kostnaden inkluderar:
- Själva testet (leverantörens arvode)
- Intern tid för scope-definition och koordinering (ofta 10–20 timmar)
- Åtgärdsarbete efter testet (den största dolda kostnaden)
- Omtest för att verifiera åtgärder (ofta 15–25 % av originaltestet)
En organisation med en AWS-baserad SaaS-produkt och 50 anställda bör budgetera cirka 150 000–300 000 SEK årligen för meningsfull säkerhetstestning, inklusive omtest.
Vanliga misstag som kostar pengar
Från Opsios arbete med säkerhetstestning och incidenthantering ser vi samma misstag upprepas:
Att köpa enbart automatiserade skanningar och kalla det pentest. Flera leverantörer säljer i praktiken Nessus- eller Qualys-rapporter under rubriken "penetrationstest". Det uppfyller varken NIS2:s anda eller hittar de sårbarheter som faktiskt exploateras.
Att testa en gång och aldrig följa upp. Ett pentest utan åtgärdsarbete är bortkastade pengar. Vi ser regelbundet samma kritiska sårbarheter dyka upp i årliga tester — ofta för att åtgärdsrekommendationerna aldrig implementerades.
Att välja leverantör enbart på pris. En rapport med 200 automatgenererade findings ger mindre värde än en rapport med 15 manuellt verifierade sårbarheter med tydliga exploateringsvägar och affärskonsekvens.
Att inte testa molnkonfigurationer. Traditionella pentestföretag testar ofta applikationer och nätverk men missar IAM-konfigurationer, resurspoliciyer och tjänsteinteraktioner i molnmiljön. Om ni kör i AWS eller Azure, kräv att leverantören har dokumenterad molnkompetens.
Så väljer ni leverantör: en checklista
| Kriterium | Varför det spelar roll |
|---|---|
| Individuella testarcertifieringar (OSCP, OSCE3, CREST CRT) | Garanterar praktisk kompetens, inte bara teoretisk |
| Andel manuell testtid (bör vara >60 %) | Säkerställer att ni betalar för expert, inte för verktyg |
| Exempelrapport tillgänglig | Visar rapportkvalitet och kommunikationsförmåga |
| Erfarenhet av er molnplattform | AWS, Azure och GCP har helt olika attackytor |
| Omtest inkluderat eller erbjudet | Utan omtest vet ni inte om åtgärderna fungerade |
| Svensk juridisk enhet eller GDPR-avtal | Testerna innebär åtkomst till känsliga system — dataskydd är kritiskt |
| Oberoende från er driftleverantör | Den som byggt miljön bör inte vara den enda som testar den |
Den sista punkten är viktig: om samma leverantör ansvarar för drift och säkerhetstestning finns en inneboende intressekonflikt. Använd gärna er Managerad DevOps partner för daglig drift, men låt en oberoende part utföra pentesterna.
Att bygga en långsiktig teststrategi
Engångstester ger en ögonblicksbild. En mogen säkerhetsteststrategi kombinerar flera metoder:
- Kontinuerlig sårbarhetsskanning — automatiserad, daglig, integrerad i CI/CD
- Applikationspentester — manuella, vid release av större funktioner
- Infrastrukturpentester — årliga, inkluderande molnkonfigurationer
- Red team-övningar — vart 2–3 år för att testa hela organisationens försvarsförmåga
- Bug bounty-program — kontinuerligt, kompletterande perspektiv från externa forskare
Denna kombination ger en totalkostnad på kanske 300 000–600 000 SEK per år för en medelstor organisation — men det motsvarar ofta mindre än en tiondel av vad en enda allvarlig säkerhetsincident kostar i direkta utgifter, för att inte tala om förlorat förtroende och regulatoriska konsekvenser.
Vanliga frågor
Vad kostar ett penetrationstest för ett mindre företag?
Ett avgränsat test av en extern webbapplikation eller ett mindre nätverkssegment landar ofta på 40 000–100 000 SEK. Priset beror på antalet IP-adresser, applikationens komplexitet och om testet inkluderar social engineering. För företag med enklare IT-miljöer räcker ofta ett fokuserat test som upprepas årligen.
Hur ofta bör vi genomföra penetrationstest?
Minst årligen, och efter varje större förändring i infrastruktur eller applikationer. NIS2 kräver att organisationer vidtar proportionella säkerhetsåtgärder, vilket i praktiken innebär regelbunden testning. Verksamheter med hög ändringstakt bör testa kvartalsvis eller integrera kontinuerlig säkerhetstestning i sin CI/CD-pipeline.
Vad är skillnaden mellan sårbarhetsskanning och penetrationstest?
En sårbarhetsskanning är automatiserad och identifierar kända brister mot en databas. Ett penetrationstest går längre — en människa försöker aktivt exploatera sårbarheterna, kedja dem samman och eskalera åtkomst precis som en verklig angripare. Skanningen hittar symptom; pentestet bevisar konsekvensen.
Täcker NIS2 kravet om man bara gör automatiserade skanningar?
Sannolikt inte. NIS2-direktivet ställer krav på riskbaserade och proportionella åtgärder. För organisationer med affärskritiska system räcker inte enbart automatiserade skanningar — tillsynsmyndigheten förväntar sig att ni kan visa att ni testat mot realistiska hotscenarier, vilket kräver manuell analys.
Kan vi använda vår molnleverantörs inbyggda säkerhetsverktyg istället?
AWS Inspector, Azure Defender och Google Security Command Center är värdefulla för kontinuerlig övervakning men ersätter inte pentester. Inbyggda verktyg testar konfigurationer och kända CVE:er — de simulerar inte en angripares beteende över tjänstegränser och affärslogik. Använd båda: automatiserad övervakning dagligen, pentest minst årligen.
Relaterade artiklar
Om författaren
Group COO & CISO at Opsio
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.
