Bedömningen är också ett krav

Det finns ett sätt att ta sig an en ny föreskrift som känns både grundligt och effektivt. Man skriver ut den, tar en överstrykningspenna och markerar varje mening som innehåller ordet ska. Sedan förs de gula raderna över till ett kalkylblad, var och en får en ansvarig och ett datum, och resultatet kallas en plan. Arbetet går fort, det ser ordnat ut och det går att visa upp för en styrelse.

MCFFS 2026:11 straffar den metoden hårdare än de flesta regelverk gör. Föreskriften om säkerhetsåtgärder och ledningens utbildning beslutades av Myndigheten för civilt försvar den 15 juni 2026 och träder i kraft den 1 oktober. Den förvaltas numera av NCSC vid FRA, som tog över föreskriftsrätten den 1 juli. Jag skriver det här i september 2026, alltså med drygt en vecka kvar, och de tjugosju sidorna är den text som fyller cybersäkerhetslagens krav på systematiskt och riskbaserat arbete med faktiskt innehåll.

Problemet med överstrykningspennan är att det som blir gult inte är samma sak som det ni behöver göra. Säkerhetskopiering står inte som ska. Kryptering av er information står inte som ska. Krisorganisation står inte som ska. Ingen av dem är för den skull frivillig. De står i en annan form, och den formen är föreskriftens mest karaktäristiska drag.

Fyra sätt att säga att något behövs

Föreskriften uttrycker sina krav på fyra olika sätt, och varje sätt kräver sin egen sorts arbete.

Ska. Ett absolut krav utan utrymme för egen bedömning. Verksamhetsutövaren ska utse roller för samordning av cybersäkerhetsarbetet och ska utse informationsägare och systemägare, enligt 3 kap. 5 §. Valda säkerhetsåtgärder och de risker de omhändertar ska dokumenteras i en åtgärdsplan, enligt 3 kap. 13 §. Ledningen ska informeras om genomförandet och om nivån av cybersäkerhet vid behov men minst en gång per år. Den digitala miljön ska delas in i segment med endast godkända informationsflöden mellan dem. Flerfaktorsautentisering ska användas för systemadministrativ åtkomst och för personals och leverantörers åtkomst via externt nätverk. Säkerhetsuppdateringar i it-segment ska genomföras skyndsamt.

Bör. Allmänna råd, satta i egna rutor efter paragraferna. De är inte tvingande, men de beskriver myndighetens uppfattning om en rimlig nivå. Här ligger hänvisningen till SS-ISO/IEC 27001:2022 och SS-EN ISO/IEC 27002:2022 som stöd för arbetet, rådet att påbörja införandet av en säkerhetsuppdatering inom 72 timmar från att skyddet finns tillgängligt, och rådet att öva krishanteringen minst en gång per år. Ni får avvika, men ni behöver då kunna förklara varför och nå samma syfte på annat sätt. Ett avsteg utan motivering är inte ett avsteg, det är ett glapp.

Identifiera och hantera behovet av. Detta är föreskriftens vanligaste formulering och den återkommer i ett trettiotal paragrafer. Hit hör säkerhetskopiering, kryptering av information, realtidsövervakning, redundanta funktioner i produktionsmiljön, krisorganisation och att endast tillåta installation av på förhand godkänd mjukvara.

Ska, om det inte är uppenbart obehövligt. Fem paragrafer har den här formen. Anslutning till automatiska notifieringar av tekniska sårbarheter hos den nationella CSIRT-enheten, DNSSEC för de domännamn ni själva registrerat, säkerhetsloggning i produktionsmiljön, bevakning av lokaler samt bevakning och larm i särskilda it- och ot-utrymmen. Utgångspunkten är att kravet gäller. Undantaget kräver att det är uppenbart, vilket är en betydligt högre tröskel än att det känns onödigt.

Sorteringen har dessutom en dimension till, och den är lätt att missa. Samma åtgärd kan bära olika formuleringar beroende på var i miljön den ska sitta. Intrångsdetektering och intrångsskydd ska användas för it-segment i produktionsmiljön, medan motsvarande skydd för ot-segment är behovsprövat. Den som har både kontorsnät och styrsystem har alltså inte ett krav att förhålla sig till utan två, och de kräver olika arbete och olika kompetens. Bokens kapitel om säkerhet i industriella miljöer förklarar varför skillnaden är befogad. Den som sorterar kraven per åtgärd i stället för per miljö tappar bort den.

Bedömningen är själv ett krav

Den tredje formuleringen är den som oftast läses fel. Många uppfattar identifiera och hantera behovet av som en artighetsfras, ungefär som att myndigheten tycker att det vore bra men inte vill kräva det. Så är det inte.

Formuleringen rymmer två steg. Först ska ni avgöra om behovet finns, och det avgörandet ska vila på er riskhantering och er informationsklassning. Sedan ska ni hantera behovet, alltså genomföra åtgärden om behovet finns. Det som är tvingande är hela rörelsen, inte bara andra halvan. Kommer ni fram till att behovet saknas har ni uppfyllt kravet, förutsatt att ni faktiskt kommit fram till det och kan visa hur.

Skillnaden mellan att ha bedömt och att inte ha tänkt på saken är osynlig i en miljö men uppenbar i ett dokument. Det är därför bedömningen behöver skrivas ned, och därför den behöver mer än en slutsats. En användbar bedömning säger fem saker.

• Vilket krav den gäller, och vilken del av den digitala miljön
• Vilket underlag den vilar på, alltså vilken riskanalys och vilken informationsklassning
• Vad slutsatsen blev och vilka skäl som bär den
• Vem som fattade beslutet och när
• När den ska omprövas

Den sista raden är den som oftast saknas. En behovsbedömning är giltig mot en verklighet, och verkligheten byter skepnad. Ett system som i dag behandlar information utan särskilt skyddsbehov kan om arton månader ha blivit den plats där allt samlas. Sätt omprövningsdatumet samma dag som ni fattar beslutet, medan skälen är färska. Bokens kapitel om riskanalys och gap-analys beskriver riskregistret som levande eller värdelöst. Behovsbedömningarna lyder under exakt samma regel.

Vem som skriver under har också betydelse. En bedömning som landar i att en åtgärd inte behövs är i praktiken ett beslut att acceptera den risk åtgärden skulle ha dämpat, och den sortens beslut hör hemma hos någon som har mandat att fatta det. I många organisationer görs bedömningarna i huvudet på den som kan systemet bäst, och stannar där. Det är sällan illvilja, det är frånvaron av en rutin. Föreskriften löser inte den saken åt er, men den gör konsekvensen synlig, eftersom en tillsyn kommer att fråga efter beslutet och inte efter uppfattningen.

Det är precis vad ett ledningssystem gör

Här finns en risk att texten låter som merarbete. Det är den inte, och det är artikelns egentliga poäng.

Läser man föreskriften i ett svep märker man vad den tar för givet. Den förutsätter att ni har en riskhantering som går att luta ett beslut mot. Den förutsätter att er information är klassad, eftersom flera krav är knutna till information i behov av utökat skydd. Den förutsätter att systemen har ägare, eftersom någon måste kunna fatta beslutet. Den förutsätter att någon kan acceptera en kvarvarande risk med mandat att göra det.

Det är samma förutsättningar som ett ledningssystem för informationssäkerhet byggs av, och det är ingen slump. De allmänna råden pekar mot ISO 27001 just därför. För den som redan arbetar så är behovsbedömningen inte ett nytt dokument utan en naturlig biprodukt av arbetet, och den 1 oktober blir en avstämning snarare än en startlinje.

För den som inte gör det blir föreskriften i stället ett mycket precist mätinstrument. Den frågar inte om ni har en pärm. Den frågar vad ni kom fram till, på vilket underlag och vem som bestämde. Utan riskanalys, utan klassning och utan utsedda ägare går den frågan inte att besvara, och då hjälper ingen mängd tekniska åtgärder. Det är också varför jag i boken behandlar ledningssystemet före de enskilda skyddsåtgärderna. Ordningen är inte en smaksak.

Det som inte går att bedöma bort

Två saker i föreskriften går inte att resonera sig ur, och de förtjänar att stå för sig själva.

Det ena är ledningens utbildning i 2 kap. 1 §. Den har ingen behovsprövning. Utbildningen ska ge ledningen kunskap nog att fastställa mål och inriktning, att bedöma vilka säkerhetsåtgärder verksamheten behöver utifrån identifierade risker, och att övervaka att åtgärderna genomförs. Lägg märke till mittendelen. Lagstiftaren har lagt bedömningsförmågan i ledningens knä, vilket gör ledningens ansvar till något annat än en formalitet. Kravet når dessutom längre än resten av föreskriften. För verksamhetsutövare som uteslutande verkar inom digital infrastruktur, digitala leverantörer, förvaltning av IKT-tjänster, post- och budtjänster eller rymden gäller enligt 1 kap. 1 § endast just utbildningskravet. De fem sektorerna slipper alltså det övriga, men inte det.

Det andra är tiden. Föreskriften saknar övergångsbestämmelser. Det finns ingen infasning och inget senarelagt kapitel, bara raden om att författningen träder i kraft den 1 oktober 2026. NCSC har aviserat en introduktion i samband med ikraftträdandet och en föreskriftsvägledning i slutet av året. Vänta inte på den. Gör er egen tolkning nu och dokumentera den, så har ni något att stämma av vägledningen mot när den kommer, i stället för ett tomt halvår att förklara. För den som vill ha den operativa genomgången med mall och ordningsföljd har jag skrivit en sådan hos VER&IT.

En tredje sak är värd att nämna, även om den inte är ett krav på samma sätt. Föreskriften anger i 1 kap. 2 § att om någon annan författning ställer högre krav så tillämpas den bestämmelsen. För den som också bedriver säkerhetskänslig verksamhet eller lyder under sektorsregler betyder det att MCFFS 2026:11 är ett golv och inte ett tak. Det är samma resonemang som boken för om cybersäkerhetslagen i stort, och det tål att upprepas varje gång en ny föreskrift landar.

Bokens regelverkskarta står sig i övrigt. Det som händer den 1 oktober är inte att kartan ritas om, utan att en av dess rutor fylls med text.

En föreskrift kan tvinga fram en åtgärd. Den kan också, som här, tvinga fram ett omdöme. Det senare är svårare att kräva och betydligt mer värt att ha, eftersom ett omdöme följer med till nästa system och nästa år medan en åtgärd stannar där den sattes. MCFFS 2026:11 kan inte göra bedömningen åt er. Den kan bara kräva att den finns.