NIS2-krav på pentest, vad måste du göra och hur dokumenterar du det
Säg det rakt: är pentest obligatoriskt?
Nej, inte explicit. NIS2 listar inte penetrationstestning som obligatoriskt åtgärdsområde.
Ja, i praktiken. Art. 21 kräver "lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder", och MSB:s tillsynspraxis behandlar pentest som rimlig åtgärd. Om du inte gör pentest måste du dokumentera varför du inte gör det, vilket är svårare än att bara göra det.
Vilka NIS2-artiklar pekar mot pentest?
Art. 21(2)(e): Säkerhet vid förvärv, utveckling och underhåll
"Säkerhet vid förvärv, utveckling och underhåll av nätverks- och informationssystem, inklusive hantering och utlämnande av sårbarheter."
Detta är huvudankaret. Pentest är hur du verifierar att system du förvärvat (SaaS, licensierade produkter), utvecklat själv eller underhåller faktiskt har den säkerhet du tror. "Hantering av sårbarheter" innebär:
- Aktiv upptäckt (pentest, sårbarhetsskanning, bug bounty)
- Triage (vilka är riktiga, vilka är false positives, vilken prioritering)
- Åtgärder (patching, kompensaterande kontroller)
- Verifiering (återtest)
Art. 21(2)(f): Mätning + utvärdering av åtgärdernas effektivitet
"Strategier och förfaranden för att utvärdera effektiviteten i åtgärderna för hantering av cybersäkerhetsrisker."
Pentest är mätinstrumentet för cybersäkerhetsåtgärdernas effektivitet. Du kan ha installerat WAF, EDR, MFA, men hur vet du att de fungerar? Pentest verifierar genom kontrollerad attack-simulering.
Art. 21(2)(d): Säkerhet i leverantörskedjan
"Säkerhet i leverantörskedjan, inbegripet säkerhetsrelaterade aspekter av förhållanden mellan varje entitet och dess direkta leverantörer eller tjänsteleverantörer."
Pentest av kritiska leverantörers system + verifiering att deras säkerhet matchar din risktolerans. För svenska entiteter med molnberoenden, SaaS-leverantörer, ut-source:ad utveckling, vendor-pentest är ofta enda kontrollerbara åtgärden.
Art. 21(2)(b): Incidenthantering
Indirekt: pentest tränar både teknik (SIEM-detektering) och process (response-team) i kontrollerad miljö. Red Team-uppdrag fungerar som tabletop-exercise på steroider.
Art. 23: Incidentrapportering
Indirekt: pentest hittar incidenter du inte visste om. Om pentestern hittar pågående angrepp utlöses incidentrapporteringen.
Vad förväntar sig MSB se i dokumentationen?
Per MSB:s tillsynsmodell (publicerad 2025-12) är audit-fokus på processer, inte enskilda fynd. Du måste kunna visa:
1. Pentest-policy
Ett dokument som beskriver:
- Vilka system som täcks av återkommande pentest
- Vilken frekvens (årligen / kvartalsvis / vid större förändring)
- Vilken metodik (OWASP Testing Guide, PTES, NIST 800-115)
- Hur fynd hanteras (SLA per allvarsgrad)
- Vem som godkänner att tester körs
2. Genomförandebevis
- Senaste 3 pentest-rapporterna (med scope-dokument, leverantörsidentitet, datum)
- Återtest-bevis efter åtgärder
- Spårbarhet från fynd till ärende i ditt ärendehanteringssystem
3. Riskhanteringsbeslut
- Vilka fynd har inte åtgärdats och varför (kompensaterande kontroller, accepterad risk)
- Vem på ledningsnivå har godkänt accepterad risk (NIS2 kräver ledningens godkännande)
4. Trender
- Antal högsta-allvar-fynd per kvartal (trend nedåt = bra säkerhetsmognad)
- Tid från upptäckt till åtgärd per allvarsgrad
5. Leverantörsrisk
- Vilka kritiska leverantörer har egna pentest-rapporter delat med dig
- Hur ofta begärs uppdaterad rapport
Pentest-frekvens, vad räknas som "lämpligt och proportionerligt"?
NIS2 säger inte "minst en gång per år". Men tillsynspraxis från MSB + andra EU-länders motsvarigheter konvergerar på:
| Risknivå | Manuellt pentest | Kontinuerlig skanning |
|---|---|---|
| Hög (väsentlig entitet, kritisk infrastruktur) | 2 ggr/år + efter varje större change | Dagligen, alla externa tillgångar |
| Mellan (viktig entitet, finansiell, hälsodata) | Årligen + efter större change | Dagligen |
| Låg (mindre digital aktör) | Vartannat år eller stora releaser | Vid behov |
Om du har bara ett årligt pentest och inget kontinuerligt mått: räkna med tillsynsanmärkning eftersom 360 dagars exponering mellan tester inte räknas som "proportionerligt" för väsentliga entiteter.
Vanliga misstag i NIS2-pentest-program
1. Att tro punktvisa pentest räcker
Ett pentest från januari säger inget om sårbarheter i juni. NIS2 art. 21(2)(f) kräver kontinuerlig utvärdering. Kombinera årlig manuell pentest med daglig automatiserad skanning.
2. Att aldrig återtesta
Om du inte återtestar efter åtgärder kan du inte bevisa att risken är mitigerad. NIS2-auditor frågar specifikt: "hur vet du att den här sårbarheten är fixad?", utan återtest är svaret bara "utvecklaren sa det".
3. Att inte testa leverantörer
Art. 21(2)(d) sätter explicit krav på leverantörsrisk. Att begära pentest-rapport från kritiska SaaS-leverantörer är minimum. Aktivt pentesta dem (med tillstånd) är bättre.
4. Att lägga pentest utan ledningssignering
NIS2 kräver att ledningen ska godkänna riskhanteringsåtgärderna. Pentest-fynd över viss tröskel ska eskaleras till styrelse. Dokumentera detta, vem fick rapporten, när, vilka åtgärdsbeslut togs.
5. Att inte mappa fynd mot NIS2-artiklar
Räcker inte med CVSS-poäng. NIS2-rapport ska visa: "denna sårbarhet bryter mot art. 21(2)(h) (kryptering)", så ledningen + auditor förstår implikation utöver tekniskt djup.
Hur Pentesting.se levererar NIS2-kompatibel pentest
Konkret vad vi gör annorlunda mot generisk pentest-leverans:
- Mappar varje fynd mot NIS2-artiklar automatiskt i rapporten, inte bara CWE/OWASP
- Daglig automatiserad skanning ger kontinuerlig utvärdering (art. 21(2)(f))
- Vendor-skanning av kritiska leverantörers publika exponering, täcker art. 21(2)(d)
- MSB-redo-rapportformat, kan delas direkt med tillsyn utan omarbetning
- Återtest ingår, automatiskt schemalagt 30 dagar efter åtgärdsförslag
- Ledningsrapport, kortfattat executive summary för styrelseeskalering
- Incident-redo, om vi hittar pågående intrång aktiveras MSB-anmälningsmallar inom 24h-fönstret
Vad gör jag som NIS2-omfattad organisation just nu?
Tre steg, gör dem i ordning:
- Inventera vad du har, vilka pentest-rapporter har du senaste 24 månaderna? Vad täcker de? Vad täcker de inte?
- Identifiera gap, applikationer / infrastruktur / leverantörer som inte täckts. Lista i prioritet efter affärskritikalitet.
- Etablera årshjul, månadlig: kontinuerlig skanning. Kvartalsvis: vendor-rapport-uppdatering. Halvårlig eller årlig: manuell pentest. Vid större change: ad-hoc pentest.
Behöver du hjälp att bygga eller revidera NIS2-pentest-programmet? Kontakta oss, vi gör NIS2-mappning som standardleverans, inte tillval.
Läs också: