Vad ett penetrationstest är och när företaget behöver det

Skanning, granskning och penetrationstest är tre olika arbeten med tre olika priser. Vilket av dem svarar på din fråga, och vad svensk rätt faktiskt kräver.

Du ber om offert på webbplatsens säkerhet och får tre stycken som skiljer sig tiofalt, och i den ena står ”sårbarhetsskanning”, i den andra ”säkerhetsgranskning”, i den tredje ”penetrationstest”, men i alla tre säljs samma ord ”säkerhet”, som inte säger något om det som skiljer dem. Det är inte ett arbete i tre steg och inte tre priser för samma sak, utan tre olika arbeten som svarar på tre olika frågor, därför är första steget inte att jämföra priser, utan att förstå vilken av de tre frågorna du faktiskt vill ha svar på.

Den här artikeln svarar på två: vad ett penetrationstest är och om det behövs just för ditt företag. Den andra frågan är den viktigaste, eftersom de flesta svenska små och medelstora företag inte träffas av någon författning som kräver ett penetrationstest efter namn, och en offert som tiger om det säljer dig rätt tjänst vid fel tillfälle.

Vi skriver det här och säljer säkerhetsgranskning, och det är ingen motsägelse, för en granskning där det finns rum för manuell kontroll, och ett penetrationstest som vissa regelverk faktiskt kräver, är inte samma arbete, men ett företag som köper det andra när det behövde det första betalar mer och får veta mindre.

Tre arbeten som säljs under liknande namn

Branschens terminologi är rörig här, men under den finns en tydlig gräns som bäst namnges av standardiseringsorganet: NIST SP 800-115 definierar penetrationstest som säkerhetstestning där bedömare härmar verkliga angrepp för att hitta vägar runt systemets skydd, och anger att det söker kombinationer av sårbarheter, inte enstaka fynd. Samma publikation beskriver sårbarhetsskanning som en teknik för att identifiera resurser och de kända sårbarheter som hör till dem.

I praktiken betyder det fyra skilda arbeten, som det är värt att namnge var för sig. Skanning är automatisk, och där jämför verktyget ditt system med en databas över kända sårbarheter och lämnar en lista. Validering och rangordning av skanningsfynd är samma lista, som en människa har kontrollerat och sorterat, vanligtvis utan att utnyttja någon av de sårbarheter som hittats. Penetrationstest är ett människostyrt arbete där de svaga punkter som hittats utnyttjas och kopplas ihop i en kedja, för att ta reda på hur långt en angripare faktiskt kommer. Efterlevnadsrevision svarar på en helt annan fråga: om systemet uppfyller en namngiven standard eller norm.

Gränsen mellan de tre första formuleras tydligast av betalkortsstandarden, som gör det inte med en definition utan med syftet: PCI SSC:s vägledning skiljer penetrationstest från skanning efter målet: skanning identifierar, sorterar och rapporterar sårbarheter; testet söker sätt att utnyttja dem för att gå runt systemets skydd. PCI SSC tillägger båda sidorna i sin standard: skanning i sig är inte ett penetrationstest, och ett test som bara försöker utnyttja skannerns fynd är inte heller tillräckligt.

Därför är frågan ”behöver du ett penetrationstest” inte en fråga om budget, utan om vad du vill ha svar på: om det finns kända svaga punkter i ditt system, eller om någon verkligen kan göra något med dem.

Vad vart och ett av dem svarar på — och vad det inte säger

Skanning svarar snabbt och billigt, och dess svaga punkt är sammanhanget, för verktyget vet inte vilken av de hundra markerade raderna som sitter i ditt betalningsformulär och vilken som sitter i en testmiljö som ingen når från internet, och det vet inte heller att två var för sig harmlösa fel tillsammans ger åtkomst till databasen — därför är listan början på ett arbete, inte arbetets resultat.

Penetrationstest svarar långsammare och dyrare, och värdet sitter just i kedjan, för testaren söker inte ”finns det en sårbarhet här”, utan ”vad kan jag göra med den” — om man från det publika formuläret kan nå administratörsrättigheter, om man från ett kundkonto kan se en annan kunds uppgifter, om man från testmiljön kan nå produktionsdatabasen. Svaret på den frågan är det som en vd förstår utan översättning.

Efterlevnadsrevision gör varken det ena eller det andra, för den kontrollerar om systemet uppfyller en norm, och resultatet är ett utlåtande om efterlevnad, inte en lista med tekniska svagheter; just därför kan ett företag klara en efterlevnadsrevision och samma vecka bli hackat, och det är ingen motsägelse, för två dokument svarar på två olika frågor.

Inget av de här arbetena ersätter de andra och inget av dem är ”bättre” än de andra, därför är den enda meningsfulla frågan vilket av dem som just nu svarar på det du faktiskt behöver veta.

Ordoklarheten är inte bara ett lettiskt problem, och det syns när man jämför marknader: i Finland, Sverige och Norge säljer marknaden två arbeten — skanning och penetrationstest — och mellanläget har inget namn; det räknas som skanningens resultat, inte som en egen tjänst. I Tyskland är det tvärtom, för där brukar ett enda ord beteckna alla tre arbetena, inklusive själva testet, och just därför är namnet den sämsta tänkbara kompassen när offerter jämförs, medan den enda säkra frågan förblir den om de sårbarheter som hittats kommer att utnyttjas.

Kräver lagen det just av dig

Här är det värt att vara precis, för det är här offerterna oftast överdriver: i Sverige kräver ingen allmänt tillämplig författning ett penetrationstest efter namn av varje företag som har en webbplats.

Cybersäkerhetslagen (2025:1506), som trädde i kraft den 15 januari 2026 och genomför EU:s direktiv 2022/2555, lägger skyldigheter på verksamhetsutövare: anmälan, säkerhetsåtgärder och incidentrapportering. Penetrationstest nämns inte efter namn i någon paragraf i lagen.

Det som föreskrifterna om säkerhetsåtgärder (MCFFS 2026:11) namnger, med ikraftträdande den 1 oktober 2026, är säkerhetstester och granskningar innan ett system driftsätts första gången och därefter löpande säkerhetstester — inte ett penetrationstest med treårsintervall, och bara om du omfattas av lagen. Cybersäkerhetslagen ger dessutom tillsynsmyndigheten rätt att genomföra säkerhetsrevisioner och säkerhetsskanningar hos den som står under tillsyn.

Det är två saker samtidigt, inte en: den som inte är verksamhetsutövare enligt lagen får ingen skyldighet ur de här bestämmelserna, och den som är det — väsentlig eller viktig — får fortfarande inte ett namngivet krav på penetrationstest, därför är första steget inte att begära offert, utan att bedöma om du över huvud taget omfattas.

Så vet du om du omfattas

Cybersäkerhetslagen räknar inte upp företag efter namn, utan beskriver sektorer och storlek, och skyldigheten att bedöma sin egen status ligger på företaget självt, vilket i praktiken betyder två frågor: ingår din verksamhet i något av de områden som lagen pekar ut, och når företaget upp till den storlekströskel som gäller. Båda ska du svara på själv, och svaret ska dokumenteras — just därför är den första utgiften på det här området oftast juridisk rådgivning, inte en teknisk tjänst.

Om svaret är ”nej” gäller de följande punkterna om säkerhetstester inte alls, och om svaret är ”ja” kommer nästa fråga om du är väsentlig eller viktig verksamhetsutövare. Skillnaden mellan väsentlig och viktig styr hur tillsynen ser ut, inte ett namngivet krav på penetrationstest, och ett företag kan omfattas av lagen utan att något namngivet krav på penetrationstest träffar något av dess system.

Det finns också en tredje väg, som inte kräver att du själv beställer något: tillsynsmyndigheten får genomföra säkerhetsrevisioner och säkerhetsskanningar hos den som står under tillsyn. Det är inte en planerbar skyldighet, men det är ett skäl att veta vem på din sida som skulle svara på en sådan tillsynsåtgärd.

Övriga trösklar namnger testning, inte penetrationstest

Artikel 32 i dataskyddsförordningen kräver att man regelbundet testar, undersöker och utvärderar effektiviteten i säkerhetsåtgärderna, och kravets omfattning är knuten till risken. Det är inte samma sak som en skyldighet att en gång om året beställa ett penetrationstest, och en offert som lägger fram artikel 32 som just det återger förordningen lösare än den är skriven. Skyldigheten att kunna visa att testning över huvud taget sker är verklig; skyldigheten att välja just den här testformen följer inte av artikel 32.

Betalkortsstandarden PCI DSS namnger i krav 11.4 penetrationstestet rakt av, en gång var tolfte månad och efter väsentliga ändringar, men det är en avtalsenlig skyldighet och gäller hur du tar emot kort. En webbutik som lägger hela betalningen hos en betaltjänstleverantör och själv inte behandlar kortuppgifter, och de övriga där kortuppgifter hamnar i miljön, svarar på det kravet olika. Det är en fråga som din inlösenbank svarar på, inte artikeln.

I finanssektorn kräver förordning (EU) 2022/2554 regelbunden testning, och den föreskriver hotbildsstyrd penetrationstestning (TLPT) bara för de institut som tillsynsmyndigheten särskilt har anvisat. Standarden ISO/IEC 27001 kräver sårbarhetshantering och säkerhetstestning, utan att kräva penetrationstest efter namn; påståendet att certifieringen inte utfärdas utan ett sådant är vanligt och står inte i standarden.

Om ingen av de här trösklarna träffar dig har du ingen författningsenlig skyldighet att beställa ett penetrationstest, och det betyder inte att det inte finns något att göra, utan att det som ska göras är något annat.

Om ingen tröskel är passerad

För ett företag som inte omfattas, inte behandlar kortuppgifter och inte är verksamt i finanssektorn är det meningsfullaste arbetet oftast det som sker regelbundet, inte som ett enstaka projekt vart tredje år. Det är uppdateringar som har en ansvarig och en tidsfrist; säkerhetskopior som någon en gång har återställt och försäkrat sig om att de verkligen går att återställa; flerfaktorsautentisering för administratörskonton, som föreskrifterna namnger särskilt för den som omfattas och som är lika användbar för alla andra; och regelbunden skanning, vars resultat någon faktiskt läser.

Det här är inte ett sämre svar, utan ett annat slags arbete. De flesta intrång vi arbetar med börjar inte med ett sofistikerat angrepp, utan med en ouppdaterad komponent eller ett lösenord som också dög någon annanstans, och ett penetrationstest som görs vart tredje år skyddar inte mot det. Om din webbplats redan har drabbats är ordningen en annan och den beskrivs i en separat artikel om hur du återställer en hackad webbplats.

Ett penetrationstest blir motiverat när det finns något att förlora, och när förlustens storlek är större än testets pris: ett system där andra människors uppgifter ligger, en integration som rör pengar, eller en beställare som kräver ett bevis. Fram till dess är det rätt arbete i fel ordning.

Vad som händer under testet

Arbetet börjar med att omfattningen fastställs och slutar med en rapport, och däremellan ligger tre steg som det är värt att förstå innan offerterna jämförs, för just de förklarar varför ett test kostar det det kostar, och varför ett annat för samma system kostar tio gånger mindre.

Första steget är kartläggning, där testaren samlar in allt som går att få veta om systemet utifrån — vilka adresser som är publika, vilka tekniker och versioner som syns, var inloggningsformulären sitter, vilka filer som är åtkomliga utan behörighet. I det här steget utnyttjas ännu ingenting, men just här hittas oftast de fynd som ingen väntat sig: en glömd testmiljö, en öppen kataloglistning, en säkerhetskopia som ligger under en förutsägbar adress.

Andra steget är själva prövningen, där de automatiska verktygen körs för att inte missa det kända, men besluten fattas av en människa som kontrollerar om fyndet är äkta, försöker utnyttja det och ser vad det ger. Här uppstår kedjan — åtkomst till ett konto, därifrån åtkomst till en funktion som inte skulle ha varit nåbar, därifrån åtkomst till data. Var för sig är ingen av stegen dramatisk; tillsammans är de en berättelse.

Tredje steget är att bevisa och skriva ner, för varje fynd måste lämna ett bevis som går att upprepa: vilken begäran som skickades, vad svaret blev, vad som ändrades. Utan det är rapporten en åsikt, och utvecklaren som tar emot den lägger en dag på att försöka förstå vad testaren egentligen såg.

Därför ser tidsramarna ut som de gör: testet av en enda liten webbplats är några dagar, men ett system med flera roller, integrationer och betalningar är veckor, och en offert som lovar ett fullständigt penetrationstest på en dag beskriver inte ett test, utan en skanning.

Varför offerterna skiljer sig tiofalt

När två offerter för en och samma webbplats skiljer sig tio gånger är skillnaden nästan aldrig vinstmarginalen, och den sitter nästan alltid i omfattningen och metoden: den ena erbjuder en automatisk skanning med ett verktyg som startas på en timme och vars rapport samma verktyg genererar, medan den andra erbjuder en veckas människarbete där verktygen bara är början, och just den skillnaden är det som namnet ”säkerhetskontroll” döljer i båda fallen.

Den andra prissättande faktorn är systemets komplexitet, och den kan bedömas innan samtalet börjar: en enda publik webbplats utan användarkonton är ett arbete, men ett system med flera roller, betalningar, yttre integration och uppgifter som tillhör kunder är något helt annat, för varje roll är en egen gräns att pröva och varje integration är en plats där två system litar mer på varandra än de borde.

Det tredje är vad du får efter testet och hur länge utföraren stannar kvar: en rapport utan prioriteringar, utan bevis och utan omtest kostar mindre därför att den är ett mindre arbete, och för ett företag som sedan ska rätta fynden är just de tre sakerna det som avgör om dokumentet blir en att-göra-lista eller en pärm som ingen längre öppnar.

Därför går offerter att jämföra efter pris bara när omfattningen är skriven likadant, och det enklaste sättet att få till det är att skriva omfattningen själva och be alla offerera mot den, inte att låta varje utförare definiera sin egen.

När testet åldras

Resultatet av ett penetrationstest beskriver ett visst system vid ett visst datum, vilket är uppenbart, och ändå är det just här den mesta missförståelsen mellan utförare och beställare uppstår, för en rapport som är ett år gammal beskriver kod som sedan dess har ändrats dussintals gånger.

De författningsenliga tidsfristerna medger det själva: i föreskrifterna står säkerhetstester före första driftsättningen sida vid sida med de löpande testerna, och i betalkortsstandarden står årsintervallet sida vid sida med ”efter väsentliga ändringar”, så att kalendern i båda fallen bara är ett minimum, medan det verkliga skälet att testa är en ändring.

I praktiken betyder det att ett nytt skäl att testa är en ändring som ändrar angreppets räckvidd: en ny publik funktion, en ny integration mot ett yttre system, byte av autentisering, flytt till annat webbhotell, en ny användarroll med vidare rättigheter. Ett färgbyte eller en textjustering blir inte ett sådant skäl, hur synligt det än är.

Det andra skälet är att omgivningen har ändrats, inte din kod: en sårbarhet i ett ramverk du använder avslöjas efter testet, och ett test som inte nämnde den har inte felat, för den fanns inte då. Därför är regelbunden skanning och en process för uppdateringar det som händer mellan testerna, och testet ersätter inte det.

Utan ägarens tillstånd är samma handlingar olagliga

Ett penetrationstest skiljer sig tekniskt inte från ett angrepp, och det enda som skiljer dem är ett dokument: ägarens tillstånd, där omfattning, tid och gränser är namngivna, och som det är värt att formulera skriftligt även när lagen inte kräver det rakt av. Utan det är samma handlingar samma handlingar, och det har juridiska följder.

Praktiskt betyder det att tillståndet ges av den som systemet tillhör, inte av den som driver det. Om din webbplats körs hos ett webbhotell måste också leverantören veta att testet ska ske, för annars stoppar skyddssystemen det eller spärrar ditt konto. Om systemet rymmer en tredjepartskomponent som du inte styr över ingår den inte i omfattningen.

Omfattningens gränser ska skrivas före, inte efter, och på den listan står vilka adresser som ingår och vilka som inte gör det, om vi testar produktionsmiljön eller en kopia, vad som händer om testet avbryter tjänsten, och vem på din sida som går att nå på natten; det samtalet tar en timme och löser merparten av de tvister som annars uppstår mitt i testet.

Vad testet inte är: rött lag, bug bounty och efterlevnadskontroll

Bredvid penetrationstestet finns flera arbeten som brukar kallas för samma sak, och skillnaderna mellan dem är inte akademiska utan praktiska — de avgör vad du beställer och vad du får.

Ett rött lags uppdrag prövar inte systemet, utan försvaret: om dina människor och processer märker angreppet och vad de gör. Omfattningen är bredare, tiden längre, och en del av värdet sitter just i att den försvarande sidan inte vet att det pågår en övning. För ett företag som inte har något att märka, för att ingen läser loggarna, är det här arbetet för tidigt.

Bug bounty är en modell, inte ett test: du publicerar regler och betalar för fynd till dem som skickar in dem. Det kan hitta det en enda testare missade, men det ger varken garanti för omfattning, en tidsfrist eller en rapport som går att lägga till upphandlingsunderlaget.

Hotbildsstyrd penetrationstestning (TLPT) är ett eget, reglerat arbete i finanssektorn, och det är definierat i en EU-förordning. Om ditt företag inte är ett finansinstitut som tillsynsmyndigheten har anvisat hör den termen inte hemma i din offert.

Ytterligare en gräns som brukar rivas är den mellan ”svart”, ”vit” och ”grå låda” — hur mycket testaren redan vet om systemet från början. Det är en branschöverenskommelse, inte ett författningskrav, och den påverkar priset och vad testet kommer att hitta direkt. En testare utan åtkomst härmar en främling; en testare med konto och dokumentation når längre på samma tid. Ingen av varianterna är den rätta; frågan är vad du är rädd för.

Vad du får och hur du läser det

Testets resultat är en rapport, och värdet sitter i prioriteringarna, inte i antalet fynd, för en rapport med hundra rader där det inte står var man ska börja är precis lika oanvändbar som en skannerutskrift. En bra rapport säger för varje fynd vad angriparen kan göra med det, hur lätt, och vad som konkret ska ändras.

Det andra du ska begära är kontroll efter rättningarna, för ett fynd som är rättat och ett fynd som någon tror är rättat skiljer sig från varandra, och det enda sättet att ta reda på det är att pröva igen. Vi gör det inom trettio dagar efter rättningarna, och den fristen är värd att kräva av varje utförare.

Det tredje är vad din utvecklare ska göra med rapporten. Ett fynd som är beskrivet med ett CVE-nummer och utan sammanhang betyder sökning för utvecklaren; ett fynd som har den konkreta begäran och platsen i koden bifogad betyder en rättning. Om ett företag gör utvecklingen och ett annat testet är den skillnaden det som avgör om rättningarna görs på en vecka eller på ett kvartal.

Det fjärde är det som inte får stå i rapporten: påståendet att systemet nu är säkert. Testet visar vad som gick att göra i den givna omfattningen vid det givna datumet. Det bevisar inte att det inte finns något annat, och en utförare som lovar det säljer dig tröst.

Det finns ytterligare ett skäl att ta den här dialogen tidigare än det känns nödvändigt: ett test som sker en vecka innan systemet driftsätts hittar samma sak som det skulle ha hittat tre månader tidigare, men för att rätta fynden finns det varken tid eller budget kvar, och i praktiken slutar det med en lista som tas emot som en risk, inte med rättningar, därför är föreskrifternas krav att testa innan driftsättning skrivet som det är, och samma logik gäller också dem som inte är bundna av det kravet.

Och det sista som är värt att säga rakt ut: ett penetrationstest är inte ett intyg på att systemet är säkert, utan ett intyg på att en känd färdighet vid ett visst datum i en viss omfattning inte hittade en väg längre än till något konkret, och därför är den värdefullaste delen av rapporten ofta inte listan med fynd, utan beskrivningen av det som försöktes och misslyckades, för just den delen säger nästa testare om tre år var det inte är värt att börja från noll.

Vad du ska förbereda före samtalet

För att en offert över huvud taget ska gå att jämföra måste utföraren känna omfattningen, därför tar du fram en lista med de adresser och system som ingår, anger om vi testar produktionsmiljön eller en kopia, säger vad i systemet som inte får röras, och namnger den person som får avbryta testet.

Produktionsmiljö eller kopia

Det här är frågan som avgör både pris och risk, för ett test i produktionsmiljön visar det som verkligen är åtkomligt, och just därför kan det förstöra något: överbelasta, fylla databasen med testposter, skicka riktiga e-postmeddelanden till kunder eller fastna i ett skyddssystem som spärrar testaren och sedan också en del av dina användare.

Ett test i en kopia är säkrare och samtidigt ofullständigare, för kopian är sällan identisk: där saknas ofta de riktiga integrationerna, den riktiga datamängden och den riktiga konfigurationen, och just i konfigurationen sitter problemet ofta. Väljer du en kopia ska du skriva upp hur den skiljer sig från produktionsmiljön, för den listan är också en lista över det testet inte prövade.

Mellanvägen, som vi använder oftast: läsåtgärder i produktionsmiljön, skriv- och potentiellt förstörande åtgärder i kopian, med ett i förväg avtalat fönster och en människa som kan avbryta. Det är inte en kompromiss för prisets skull, utan ett sätt att få båda varianternas svar utan att avbryta verksamheten.

Den omvända listan duger också, alltså det som inte ingår i omfattningen, för gränser som tigande har antagits är de man senare tvistar om. Tredjepartstjänster som du inte driver ingår inte, och att testa dem utan de parternas tillstånd är samma problem som avsnittet ovan. Om din webbplats använder ett externt betalningsfönster, ett externt chattfönster eller extern analys är det andras egendom, och en offert som lovar att ”kolla dem också” lovar det den inte får.

Till sist ska du säga vad som händer med fynden efteråt: vem som rättar dem, på vilken tid, och om utföraren prövar igen efter rättningarna. Ett test utan den överenskommelsen slutar ofta med ett dokument som ingen öppnar, och det är den dyraste versionen som finns: betalt för kunskap som inte används.

Säg också vad du söker svar på, för ”vi måste uppfylla ett krav” och ”vi vill veta om någon kan komma åt kundernas uppgifter” är två olika arbeten med två olika priser, och en utförare som inte frågar vilket av dem som är ditt kommer att erbjuda det som passar utföraren bäst.

Om du inte är säker på vilken sida av tröskeln du står är det värt att börja där. Den automatiska granskningen svarar oftast på frågan om de kända svaga punkterna billigare och snabbare än ett manuellt expertarbete, och resultatet säger också om penetrationstest är nästa steg. Ett samtal om omfattningen är värt att börja med en beskrivning av processen, inte med en lista över teknik, för omfattningen avgörs av det du förlorar om systemet sviker.