Kort svar: Från 1 oktober 2026 ska verksamheter som omfattas av MCFFS 2026:11 se till att deras leverantörer uppfyller samma säkerhetskrav, och komplettera äldre avtal (4 kap. 1 §). Därför får även SaaS-bolag som inte själva omfattas av lagen frågeformulär och krav på testrapporter. Ha en aktuell testrapport, åtgärdsstatus och besked om var data lagras redo. Kontrollerat 2026-09-26.
Ett frågeformulär på 200 rader dyker upp i inkorgen, med en deadline på fredag. Kunden är en region, ett energibolag eller en bank, och någonstans i formuläret står frågan: "När genomfördes ert senaste penetrationstest, och vilka fynd är åtgärdade?"
Det här är inte en engångshändelse. Kraven på leverantörer är inbyggda i föreskrifterna, och de börjar gälla 1 oktober 2026.
Varför ställer kunderna krav på er nu?
Tre regelverk pekar åt samma håll.
NIS2-direktivet kräver säkerhet i leveranskedjan (artikel 21.2 d) och att verksamheten tar hänsyn till varje leverantörs sårbarheter, produktkvalitet och säkerhetsrutiner, inklusive säker utveckling (artikel 21.3). Cybersäkerhetslagen tar in samma krav i 2 kap. 3 § punkt 4: "säkerhet i leveranskedjan".
MCFFS 2026:11 gör det konkret. Enligt 4 kap. 1 § ska verksamheten:
- se till att föreskriftens krav uppfylls av leverantören, utom i de delar verksamheten själv uppfyller dem,
- bedöma om leverantören kan uppfylla kraven under hela avtalstiden,
- se över avtal som ingicks före 1 oktober 2026 och om möjligt komplettera dem med krav på cybersäkerhet.
Den sista punkten förklarar tidpunkten. Många kunder går igenom sina befintliga avtal nu under hösten. Upphandlingsmyndigheten skrev i januari 2026 att aktörer som normalt inte omfattas av NIS2 kan bli skyldiga att uppfylla kraven genom en upphandling. Offentliga kunder kan alltså skriva in kraven i förfrågningsunderlaget.
Vad får kunderna skriva in i avtalet?
4 kap. 4 § kräver att avtalet gör det möjligt att genomföra och förvalta säkerhetsåtgärderna över tid. Det allmänna rådet listar vad ett avtal om utkontraktering bör reglera. Så här översätter vi listan till vad ni som SaaS-leverantör behöver ha på plats.
| Det allmänna rådet i 4 kap. 4 § | Vad ni behöver ha på plats |
|---|---|
| Kontaktuppgifter till en systemägare hos leverantören | En namngiven säkerhetskontakt och en funktionsadress |
| Vilken cybersäkerhetskompetens leverantören behöver ha | En kort beskrivning av vem som ansvarar för säkerheten och hur ni tar in extern kompetens |
| När och hur leverantören informerar om incidenter, hot, sårbarheter och förändringar som påverkar kraven | En rutin för att meddela kunder, med tidsgränser som ni faktiskt klarar |
| Hur risker från leverantörens underleverantörer hanteras och delges | En aktuell lista över underbiträden och var data lagras |
| Att leverantören kontrollerar hård- och mjukvara för att upptäcka skadlig kod och andra brister innan den används | Säkerhetstester före release och en rapport som visar det |
| Hur mycket leverantören ska öva incident-, kontinuitets- och krishantering tillsammans med kunden | Beredskap för en gemensam övning, till exempel en gång om året |
| Hur leverantören följer upp sin egen och underleverantörernas efterlevnad | Egen uppföljning med datum, som testrapporter och åtgärdsloggar |
| Hur kunden följer upp leverantörens efterlevnad | Material ni kan dela: rapport, sammanfattning eller svar i kundens formulär |
| Att avtalet kan sägas upp i förtid om leverantören brister | Inget att förbereda, men värt att veta att villkoret finns |
| Hur informationen återlämnas eller förstörs när avtalet upphör | En beskriven rutin för export och radering |
Ett allmänt råd är inte tvingande. I praktiken blir det ändå kundens mall, eftersom det är det enklaste sättet för kunden att visa tillsynsmyndigheten att 4 kap. 1 § är omhändertaget.
Vilka kunder ställer kraven, och vilka inte?
Kunder som omfattas av MCFFS 2026:11 i sin helhet ställer kraven ovan. Det gäller bland annat energi, transport, vård, dricksvatten, livsmedel, tillverkning och offentlig förvaltning, från medelstora företag och uppåt.
Kunder i PTS-sektorerna (digital infrastruktur, digitala leverantörer, förvaltning av IKT-tjänster mellan företag, post och rymd) följer i stället EU:s genomförandeförordning 2024/2690. Kravet på säkerhet i leveranskedjan finns där också, bara i annan form. Frågorna blir snarlika.
Kunder som inte omfattas alls kan ändå fråga, oftast för att deras egna kunder frågar dem. Vill ni veta om ert eget bolag omfattas direkt, läs Kräver cybersäkerhetslagen penetrationstest?
Vad frågar ett leverantörsformulär om säkerhetstester?
Formulären skiljer sig åt, men frågorna om säkerhetstester brukar gälla samma saker:
- datum för senaste testet och vad som ingick (vilka appar, API:er och miljöer),
- metod, till exempel OWASP WSTG eller en annan namngiven metodik,
- fynd per allvarlighetsgrad och hur många som är åtgärdade,
- om åtgärderna har omtestats och när,
- om testet gjordes av en oberoende part,
- hur ofta ni testar och vad som utlöser ett nytt test.
Cloud Security Alliances Cloud Controls Matrix (CCM v4) har en egen kontroll för penetrationstester, TVM-06, som CAIQ-formuläret bygger på. Den frågar efter en definierad process och tester av oberoende tredje part. SIG-formuläret från Shared Assessments är licensierat, och vi citerar det inte, men det frågar efter samma sorts uppgifter.
Svara konkret. "Ja, testat 2026-09-12 av Barrion enligt OWASP WSTG. Inga öppna kritiska eller höga fynd efter omtest 2026-09-19." Ett sådant svar går snabbare igenom än "vi testar regelbundet".
Vad ni skickar: intyg, sammanfattning eller hel rapport?
En hel pentestrapport visar exakt hur er applikation kan angripas. Skicka den inte till alla som frågar.
| Kundens fråga | Vad ni skickar | Varför |
|---|---|---|
| Ja/nej-fråga i ett formulär, eller en tidig säljdialog | Ett kort svar med datum, metod och åtgärdsstatus | Räcker för de flesta formulär och avslöjar inga detaljer |
| Leverantörsbedömning inför avtal eller vid avtalsgenomgång | En sammanfattning: omfattning, metod, antal fynd per allvarlighetsgrad och omteststatus | Kunden kan dokumentera sin bedömning enligt 4 kap. 1 § |
| Kunden eller dess revisor vill se detaljerna | Hela rapporten, under sekretessavtal och helst i ett läsläge snarare än som bilaga | Rimligt för stora kunder med granskningsrätt i avtalet |
| Kunden vill följa upp löpande | Resultat från återkommande tester och en logg över åtgärdade fynd | Visar att testningen pågår och inte är en ögonblicksbild |
Samma fråga utan det svenska regelverket, för kunder i andra länder, finns i vad ni skickar när kunden ber om en pentestrapport (på engelska).
Så tar Barrion fram underlaget
Barrion kör kontinuerliga AI-penetrationstester av webbapplikationer och API:er. AI-agenter testar er app på samma sätt som en angripare, säkert och icke-destruktivt, med metodik kopplad till alla 97 testfall i OWASP WSTG v4.2. Rapporten kommer som PDF, XLSX och JSON, med en täckningsmatris för WSTG. Det gör den lätt att dela i den form kunden vill ha.
Testerna kan gå enligt schema eller vid behov. Varje schemalagd körning märker fynden som nya, fortfarande öppna, åtgärdade eller återkomna, så ni kan visa kunden hur ett fynd har följts upp. Omtest av hittade problem ingår utan kostnad.
Fynden kontrolleras mot den levande appen innan de rapporteras, och bekräftade fynd kommer med den förfrågan och det svar som visar dem. Från nivån Standard (1 000 krediter) granskar en säkerhetsingenjör fynden, och djupare tester får en rapport som ingenjören har skrivit under. Det hjälper när kunden frågar om testet gjordes av en oberoende part.
Frågan om var er leverantörs data finns kommer också. Hos Barrion lagras och driftas kunddata i Sverige och AI-behandlingen sker inom EU. Alla underbiträden finns listade på vår trust-sida (på engelska). Barrion AB är ett svenskt bolag.
Barrion testar inte interna nätverk, Active Directory, mobilappar, fysisk säkerhet eller social manipulation. Om kundens formulär frågar om det behöver ni ett annat underlag för de delarna.
Se exempelrapporten (på engelska) för hur ett underlag ser ut.
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, 1 kap. 1 §, 3 kap. 19 §, 4 kap. 1 till 4 §§ (kontrollerad 2026-09-26)
Cybersäkerhetslag (2025:1506), riksdagen.se, 2 kap. 3 § (kontrollerad 2026-09-26)
Direktiv (EU) 2022/2555 (NIS2), EUR-Lex, artikel 21.2 d och 21.3 (kontrollerad 2026-09-26)
Genomförandeförordning (EU) 2024/2690, EUR-Lex (kontrollerad 2026-09-26)
Cybersäkerhetslagens (NIS2) påverkan på offentlig upphandling, Upphandlingsmyndigheten, 2026-01-19 (kontrollerad 2026-09-26)
Cloud Controls Matrix v4, Cloud Security Alliance, kontroll TVM-06 (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.