Kort svar: En sårbarhetsskanning letar automatiskt efter kända brister, som gammal programvara och felkonfigurationer. Ett penetrationstest försöker utnyttja bristerna och hittar sådant en skanner missar, till exempel att en inloggad användare kan läsa en annan kunds data. Föreskrifterna till cybersäkerhetslagen kräver säkerhetstester av uppdateringar, kända sårbarheter och konfiguration, så de flesta behöver båda.
En skanner kan ge er ett grönt resultat samma dag som en kund kan byta ett id i adressfältet och läsa en annan kunds fakturor. Båda sakerna kan vara sanna samtidigt, och det är hela skillnaden mellan metoderna.
Vad gör en sårbarhetsskanning, och vad missar den?
En sårbarhetsskanning jämför det den ser med kända mönster: programversioner, kända sårbarheter (CVE), säkerhetshuvuden, TLS-inställningar, öppna portar och vanliga felkonfigurationer. Den går snabbt, den kan köras varje dag och den hittar mycket av det som gör en app lätt att angripa.
Det den missar är det som bara finns i er app. En skanner vet inte att användare A inte ska se användare B:s order, att en rabattkod inte ska kunna användas tio gånger, eller att två ofarliga fynd tillsammans ger åtkomst till adminpanelen. Sådana fel får inga CVE-nummer.
Vad gör ett penetrationstest som en skanner inte gör?
Ett penetrationstest försöker faktiskt utnyttja svagheterna, på samma sätt som en angripare skulle göra. Testaren loggar in med olika roller, byter id:n, manipulerar anrop mot API:et och kedjar ihop fynd. Resultatet är färre fynd än i en skanningsrapport, men varje fynd har ett bevis på att det går att utnyttja och vad det leder till.
Typiska fynd som bara ett pentest hittar:
- behörighetsfel mellan kunder (IDOR), där ett id i en URL eller ett API-anrop ger åtkomst till någon annans data,
- fel i affärslogiken, som att hoppa över ett betalningssteg,
- kedjor där flera små brister tillsammans blir en allvarlig.
Vad kräver reglerna?
Reglerna skiljer oftast på skanning och test, eller ställer krav som den ena metoden täcker bättre än den andra.
| Regel | Vad den kräver | Metoden som ger underlaget |
|---|---|---|
| MCFFS 2026:11, 4 kap. 27 § p. 1 | Säkerhetstester ska kontrollera att systemen har senaste godkända version | Sårbarhetsskanning |
| MCFFS 2026:11, 4 kap. 27 § p. 2 | Publicerade sårbarheter ska vara omhändertagna | Sårbarhetsskanning, med omskanning efter åtgärd |
| MCFFS 2026:11, 4 kap. 27 § p. 3 | Valda konfigurationer ska vara införda | Skanning för det tekniska, pentest för behörigheter och roller |
| MCFFS 2026:11, 4 kap. 27 § andra stycket | Granskningar ska kontrollera att åtgärderna motsvarar systemets behov | Penetrationstest och granskning. Allmänt råd: etablerad metodik för automatiserade och manuella tester |
| EU 2024/2690, bilagan 6.10.2 b | Sårbarhetsskanningar där det är lämpligt, med planerade intervall och dokumenterat resultat | Sårbarhetsskanning |
| EU 2024/2690, bilagan 6.5.2 | Säkerhetstester enligt dokumenterad metodik, med typ, omfattning, tid och resultat, och åtgärder för kritiska fynd | Penetrationstest (ENISA:s vägledning nämner det som ett alternativ) |
| PCI DSS v4.0.1, krav 11.3 | Interna och externa sårbarhetsskanningar minst var tredje månad | Sårbarhetsskanning |
| PCI DSS v4.0.1, krav 11.4 | Penetrationstest minst var tolfte månad och efter betydande förändringar | Penetrationstest |
EU-förordningen 2024/2690 gäller bland annat molntjänster och andra digitala leverantörer. MCFFS 2026:11 gäller andra sektorer som omfattas av cybersäkerhetslagen. Vilka regler som gäller just er beskriver vi i Kräver cybersäkerhetslagen penetrationstest?
Vilken passar er?
Vår rekommendation är enkel. Skanna ofta, och pentesta det som har inloggning, API:er eller känslig data.
| Er situation | Vad ni behöver |
|---|---|
| En statisk webbplats utan inloggning | Sårbarhetsskanning räcker oftast |
| En SaaS-app eller ett API med inloggade användare och kunddata | Båda. Skanning löpande och penetrationstest regelbundet, och helst efter varje större release |
| Ni omfattas av MCFFS 2026:11 eller av 2024/2690 | Båda. Skanning för versioner, sårbarheter och konfiguration, pentest för att visa att åtgärderna håller |
| Kunder frågar efter en pentestrapport | Penetrationstest. En skanningsrapport besvarar inte den frågan |
| Kortbetalningar inom PCI DSS | Båda, med de intervall som krav 11.3 och 11.4 anger |
| Begränsad budget och ett nytt system | Börja med en gratis skanning, och lägg sedan pengarna på ett pentest av den inloggade delen |
Så gör Barrion
Barrion gör båda. Den passiva skanningen läser bara, ändrar ingenting och är säker att köra mot produktion. Den kontrollerar bland annat TLS, säkerhetshuvuden, cookies, CORS, DNS, e-postautentisering, exponerade tjänster och kända sårbarheter i JavaScript-bibliotek, utan att skicka anrop som ändrar något. Ni kan prova den gratis med webbplatsskanningen (på engelska).
AI-pentestet är det aktiva testet. AI-agenter testar er webbapp eller ert API på samma sätt som en angripare, säkert och icke-destruktivt, med olika roller och kedjade anrop, med metodik kopplad till de 97 testfallen i OWASP WSTG v4.2. Fynden kontrolleras mot den levande appen innan de rapporteras. Bekräftade fynd kommer med den förfrågan och det svar som visar dem, och det som inte gick att bekräfta markeras tydligt och får en begränsad allvarlighetsgrad. Från nivån Standard granskar en säkerhetsingenjör fynden. Omtest av hittade problem ingår.
Pentestet kan köras enligt schema eller vid behov, och skanningen övervakar appen mellan körningarna. Vad ett pentest kostar jämfört med en skanning går vi igenom i Vad kostar ett penetrationstest?
Källor
Alla källor kontrollerade 2026-09-26.
MCFFS 2026:11, föreskrifter och allmänna råd om säkerhetsåtgärder och ledningens utbildning, FRA, 4 kap. 27 § (kontrollerad 2026-09-26)
Genomförandeförordning (EU) 2024/2690, EUR-Lex, bilagan punkt 6.5 och 6.10 (kontrollerad 2026-09-26)
NIS2 Technical Implementation Guidance v1.0, ENISA, juni 2025 (kontrollerad 2026-09-26)
PCI DSS v4.0.1, PCI Security Standards Council, krav 11.3 och 11.4 (kontrollerad 2026-09-26)
OWASP Web Security Testing Guide v4.2, OWASP (kontrollerad 2026-09-26)
Barrions produktfakta, faktasida (på engelska) (kontrollerad 2026-09-26)
Uppgifterna om lagen och föreskrifterna kontrollerades . Föreskrifterna kan ändras, så vi går igenom sidan var 90:e dag.