Rättsliga ramar: LOU, NIS2 och säkerhetsskydd

Lagen om offentlig upphandling (LOU)

Upphandling av penetrationstest faller under LOU för offentliga organisationer. CPV-koderna för IT-säkerhetstjänster (72000000-serien) är relevanta. Beroende på kontraktsvärde kan ni använda:

• Direktupphandling – under aktuell beloppsgräns, enklare process men kräver fortfarande dokumentation
• Förenklat förfarande – under EU-tröskelvärdena, annonsering i nationell databas
• Öppet eller selektivt förfarande – över EU-tröskelvärdena

En vanlig fälla: organisationer försöker klämma in pentest som en del av ett större IT-driftavtal för att slippa separat upphandling. Det ger sällan bra resultat. Pentestleverantören bör vara oberoende från den som driftar miljön – annars testar räven hönshuset.

NIS2-direktivets påverkan

NIS2-direktivet, som trädde i kraft med svensk lagstiftning, ställer explicita krav på riskhantering och säkerhetstestning för väsentliga och viktiga entiteter. Artikel 21 specificerar att organisationer ska vidta "lämpliga och proportionella tekniska, operativa och organisatoriska åtgärder" – och regelbunden penetrationstestning är en av de mest konkreta åtgärderna för att uppfylla det kravet.

För upphandlingsansvariga innebär detta att penetrationstest inte längre är en "nice to have" utan en dokumenterbar del av regelefterlevnaden. IMY (Integritetsskyddsmyndigheten) och MSB (Myndigheten för samhällsskydd och beredskap) har tillsynsansvar, och avsaknad av systematisk säkerhetstestning blir svårt att försvara vid en granskning.

Säkerhetsskydd och personuppgifter

Om testet berör system som hanterar säkerhetskänslig information enligt säkerhetsskyddslagen tillkommer krav på säkerhetsprövning av konsulterna. Specificera detta tidigt – det begränsar antalet möjliga leverantörer och kräver längre ledtider. GDPR-aspekten är också värd att beakta: penetrationstester kan innebära åtkomst till personuppgifter, vilket kräver ett personuppgiftsbiträdesavtal med leverantören.

Så formulerar ni kravspecifikationen

Här är kärnan i det hela. En bra kravspecifikation för penetrationstest balanserar precision med flexibilitet – ni vill styra vad som testas och till vilken nivå, men inte diktera exakt vilka verktyg eller tekniker leverantören använder.

Obligatoriska krav (ska-krav)

Dessa bör vara binära – antingen uppfyller leverantören dem eller inte:

1. Konsultcertifieringar: Namngivna konsulter ska inneha OSCP, CREST CRT eller motsvarande praktisk certifiering. Certifikaten ska vara aktuella och verifierbara.

2. Metodikramverk: Testerna ska följa PTES (Penetration Testing Execution Standard) eller OWASP Testing Guide v4/v5 för webbapplikationer. Leverantören ska redovisa sin metodik i anbudet.

3. Oberoende: Leverantören ska inte ha deltagit i utveckling, drift eller förvaltning av systemen som testas under de senaste 24 månaderna.

4. Rapportkrav: Leverantören ska leverera en teknisk rapport med CVSS v3.1-klassificering av samtliga fynd, Proof of Concept för kritiska och höga sårbarheter, samt en ledningssammanfattning på svenska.

5. Sekretess och datahantering: Leverantören ska underteckna NDA, radera all testdata inom 30 dagar efter leverans, och dokumentera sin egen informationssäkerhetshantering (ISO 27001-certifiering eller motsvarande).

6. Kommunikation vid kritiska fynd: Leverantören ska omedelbart (inom 4 timmar) rapportera kritiska sårbarheter som medger fjärrkörning av kod eller dataläckage – inte vänta till slutrapporten.

Bör-krav (utvärderingskriterier)

Dessa ger er möjlighet att vikta kvalitet mot pris:

• Erfarenhet av liknande miljöer: Leverantören bör kunna visa referensuppdrag inom er bransch eller tekniska miljö
• Verifieringstest: Leverantören bör erbjuda kostnadsfri verifiering av att identifierade brister har åtgärdats
• Hotmodellering: Leverantören bör inkludera en inledande hotmodellering för att fokusera testinsatsen
• Löpande kommunikation: Dagliga eller varannan-dags statusmöten under testperioden

Utvärderingsmodell

Vi rekommenderar starkt att vikta kvalitet högre än pris – 60/40 eller 70/30. Ett billigt penetrationstest som missar kritiska sårbarheter är inte en besparing, det är en risk. Poängsätt erfarenhet, metodik och certifieringar separat.

Vanliga misstag som underminerar upphandlingen

Baserat på vad vi ser i praktiken – både som leverantör av managerade säkerhetstjänster och som rådgivare till kunder som upphandlar pentest – finns det återkommande misstag:

1. Scope som är för vagt. "Leverantören ska testa vår IT-miljö" är inte en specifikation. Ange IP-adressintervall, antal webbapplikationer, om interna tester ingår, om social engineering är tillåtet, och vilka system som explicit är undantagna.

2. Pris som enda utvärderingskriterium. LOU kräver inte lägsta pris – "det ekonomiskt mest fördelaktiga anbudet" kan och bör inkludera kvalitetskriterier. Ett penetrationstest för 30 000 SEK av er hela miljö är inte seriöst.

3. Avsaknad av testfönster. Specificera när testerna får genomföras. Produktionsmiljöer kräver ofta testning utanför kontorstid eller mot en speglad miljö. Utan denna specifikation riskerar ni avbrott.

4. Ingen kravställning på åtgärdsverifiering. Testet identifierar 47 sårbarheter – vem verifierar att de faktiskt är åtgärdade? Inkludera en retestningsperiod i avtalet.

5. Glömmer att involvera den tekniska personalen. Upphandlingsavdelningen formulerar kraven utan input från säkerhetsteamet. Resultatet blir juridiskt korrekt men tekniskt tandlöst.

Molnmiljöer kräver specialiserad kravställning

Allt fler svenska organisationer driftar sina system i publika molnplattformar. Det förändrar spelplanen för penetrationstest fundamentalt. AWS, Azure och GCP har alla specifika regler för penetrationstestning – AWS kräver till exempel inte längre förhandsanmälan för de flesta testtyper, medan vissa tjänster fortfarande är undantagna.

I er kravspecifikation för molnmiljöer bör ni inkludera:

• Molnkonfigurationsgranskning – IAM-policies, nätverkssäkerhetsgrupper, lagringsåtkomstkontroller. Många av de allvarligaste incidenterna beror på felkonfiguration, inte traditionella sårbarheter.
• Klargjord ansvarsfördelning – specificera tydligt att leverantören ska testa ert ansvar i shared responsibility-modellen, inte molnleverantörens infrastruktur.
• Specifika molntjänster i scope – ange om serverless-funktioner (Lambda, Azure Functions), containerorkestreringar (EKS, AKS) eller datalager (S3, Blob Storage) ska ingå.

Om er organisation kör arbetsbelastningar i eu-north-1 (Stockholm) eller Sweden Central, finns det ytterligare aspekter kring dataresidenskrav som bör adresseras i pentestleverantörens avtal – testdata som lämnar EU kan utgöra en GDPR-risk i sig.

Molnmigrering utan efterföljande säkerhetstestning är som att flytta till ett nytt hus utan att kontrollera att låsen fungerar.

Checklista för upphandlingsdokumentet

Använd denna som utgångspunkt när ni sammanställer er kravspecifikation:

Teknisk specifikation:

• [ ] Testtyper specificerade (externt, internt, webapp, molnkonfig)
• [ ] IP-intervall och applikationer listade
• [ ] Testmiljö definierad (produktion, staging, speglad)
• [ ] Testfönster angivet
• [ ] Undantagna system specificerade
• [ ] Krav på metodikramverk (PTES, OWASP)

Leverantörskvalifikation:

• [ ] Konsultcertifieringskrav (OSCP, CREST)
• [ ] Krav på namngivna konsulter
• [ ] Oberoendekrav
• [ ] Referensuppdrag
• [ ] ISO 27001 eller motsvarande

Avtal och leverans:

• [ ] NDA och sekretessförbindelser
• [ ] Personuppgiftsbiträdesavtal
• [ ] Rapportformat och språk
• [ ] CVSS-klassificering av fynd
• [ ] Proof of Concept-krav
• [ ] Tidplan för rapportleverans
• [ ] Retestningsperiod inkluderad
• [ ] Eskaleringsrutin vid kritiska fynd
• [ ] Datahantering och radering efter uppdrag

Opsios perspektiv: vad vi ser i praktiken

Från vårt SOC i Karlstad hanterar vi dagligen säkerhetshändelser som hade kunnat förebyggas med bättre testning. Ett mönster vi ser är att organisationer genomför pentest en gång, åtgärdar de mest akuta fynden, och sedan inte testar igen förrän något går snett. Det räcker inte.

Effektiv säkerhetstestning är en kontinuerlig process. Kombinera årliga djupgående penetrationstest med löpande molnsäkerhetsövervakning och automatiserade sårbarhetsskanningar. Managerade molntjänster med integrerad säkerhet ger er en baslinje som penetrationstesten sedan utmanar och validerar.

Och slutligen: ett penetrationstest är bara värdefullt om ni agerar på resultaten. Den bästa kravspecifikationen i världen hjälper inte om rapporten hamnar i en skrivbordslåda. Bygg in åtgärdsplaner, ansvar och uppföljning redan i upphandlingen – det är så ni går från säkerhetsteater till faktisk säkerhet.

Vanliga frågor

Måste penetrationstest upphandlas separat enligt LOU?

Det beror på kontraktsvärde och hur er upphandling är strukturerad. Pentest kan ingå som en del i ett större ramavtal för IT-säkerhetstjänster, men beloppet styr om det faller under direktupphandlingsgränsen. För statliga myndigheter gäller den lägre tröskeln. Separata upphandlingar ger dock ofta bättre kvalitet eftersom ni kan utvärdera specialistkompetens direkt.

Vilka certifieringar bör krävas av pentestleverantörer?

Kräv minst OSCP eller CREST-certifiering för de konsulter som faktiskt utför testerna – inte bara för företaget som helhet. OSCP visar praktisk förmåga att exploatera sårbarheter, inte bara teoretisk kunskap. För webbapplikationer är OSWE relevant. Kontrollera att certifieringarna är aktuella och att namngivna konsulter specificeras i avtalet.

Hur ofta bör penetrationstest genomföras?

Minst årligen för verksamhetskritiska system, men även efter större förändringar som migrering till ny molnplattform, lansering av nya tjänster eller betydande infrastrukturändringar. NIS2-direktivet förväntar sig regelbunden testning som del av riskhanteringen. Många av våra kunder kör kvartalsvisa tester av externt exponerade ytor och årliga djuptester.

Vad ska en pentestrapport minst innehålla?

En teknisk del med detaljerade sårbarhetsbeskrivningar, PoC-kod (Proof of Concept), CVSS-klassificering och rekommenderade åtgärder. Därtill en ledningssammanfattning som beskriver affärsrisken i klartext. Kräv att leverantören redovisar metodiken, vilka verktyg som använts, testningens omfattning och eventuella begränsningar. Utan verifierbar PoC vet ni inte om sårbarheten är verklig.

Kan vi kräva att pentestkonsulterna är säkerhetsprövade?

Ja, och för myndigheter och samhällsviktiga verksamheter bör ni göra det. Registerkontroll enligt säkerhetsskyddslagen kan krävas om testet berör säkerhetskänslig verksamhet. Ange detta tidigt i upphandlingen – det påverkar vilka leverantörer som kan lämna anbud och kräver längre ledtider.