Blogg

NIS2 Artikel 21.2 e:

Säkerhet i inköp och utveckling: bygg låset innan du flyttar in.

Jag brukar tänka så här: du flyttar inte in i ett nytt hus och hoppas att någon senare kommer förbi och sätter dit låset. Du ser till att dörren går att låsa innan du bär in soffan. Ändå gör vi ofta exakt tvärtom med digitala system. Vi köper, utvecklar eller beställer en tjänst och försöker sedan ‘skruva på säkerhet’ när allt redan är i drift.

Det är därför NIS2 artikel 21.2 e är en av de viktigaste punkterna i hela regelverket. Den handlar om att säkerhet ska finnas under hela livscykeln: vid inköp, vid utveckling och vid underhåll, inklusive sårbarhetshantering och koordinerad sårbarhetsrapportering (European Union, 2022).

Robert Willborg

Co-founder och Cheif Security Officer på OneMore Secure.

Först: vad punkt e faktiskt säger

Det är lätt att tro att 21.2 e bara handlar om upphandling. Det gör den inte. Punkt e omfattar säkerhet i förvärv, utveckling och underhåll av nätverks- och informationssystem. Den inkluderar sårbarhetshantering och rapportering av sårbarheter. Med andra ord: hur ni bygger, köper och förvaltar teknik på ett sätt som gör att den går att lita på över tid (European Union, 2022).

Svensk tillämpning: från teori till tillsyn

I Sverige trädde Cybersäkerhetslagen (2025:1506) och Cybersäkerhetsförordningen (2025:1507) i kraft den 15 januari 2026. Det innebär att NIS2 inte längre är en ‘EU‑idé’ utan en praktisk kravbild som ska kunna visas i arbete, beslut och bevis (Sveriges riksdag, 2025a; Sveriges riksdag, 2025b; Regeringen, 2026).

Den vanligaste fällan: excel, standardformulär och engångskontroll

Jag möter fortfarande upphandlingar där säkerhet hanteras via långa frågelistor som mejlas fram och tillbaka. Frågorna är ofta generiska, inte kopplade till den faktiska leveransen, och det som svaras kontrolleras sällan efter signering. Det blir som att fråga en byggfirma om de ‘brukar’ montera lås, och sedan aldrig kontrollera om dörren faktiskt går att låsa.

NIS2 pekar i en annan riktning. Säkerhet ska vara en del av livscykeln, inte ett enstaka moment. Det betyder att krav måste vara mätbara och att uppföljning måste ske under avtalstiden. Annars får du ett papper som känns tryggt och en verklighet som inte är det.

Vad sårbarhetshantering betyder utan att bli ‘security theatre’

Sårbarhet är enkelt uttryckt ett svagt ställe som kan utnyttjas. Sårbarhetshantering är arbetet att hitta dem, prioritera dem och åtgärda dem innan de blir incidenter. Det låter tekniskt, men är i grunden styrning: vem äger beslutet, hur snabbt agerar vi, och hur vet vi att det blev gjort.

För vissa typer av aktörer har EU dessutom preciserat tekniska och metodmässiga krav via en genomförandeförordning. Den förstärker att sårbarhetshantering och säkra rutiner i livscykeln ska vara systematiska, spårbara och uppdaterade (European Commission, 2024).

Den obekväma sanningen: leverantören är en del av din attackyta

När ni köper in system eller tjänster köper ni inte bara funktion. Ni köper också en framtida uppdateringskedja, en supportkedja, en komponentlista och en kultur. Om leverantören har dåliga rutiner för sårbarheter eller om de är ovilliga att svara på frågor, då är det en röd flagga. Inte för att de är ‘onda’, utan för att de blir en del av er exponering.

Det här hänger tätt ihop med artikel 21.2 d om leverantörskedjan, men 21.2 e skär djupare: den handlar om hur säkert det ni köper och bygger faktiskt är konstruerat och underhållet över tid (European Union, 2022).

Tre förslag som är realistiska och lagliga

Jag vill behålla det här som ett blogginlägg, inte en handbok. Men jag vågar säga tre saker som brukar ge effekt, och som ligger helt i linje med 21.2 e utan att jag hittar på egna krav.

· Kravställ bevis, inte löften.

· Sätt sårbarhets-SLA per risk.

· Öva uppdatering som rutin.

Kravställ bevis betyder att ni ber om konkreta artefakter: hur ser processen ut, vad mäts, och vad visar senaste perioden. Sårbarhets-SLA betyder att ni kopplar tidskrav till kritikalitet, så att allt inte blir ‘snarast’. Öva uppdatering som rutin betyder att patchning och ändringar görs kontrollerat, med rollback och tydlig kommunikation. Det är så man bygger ett lås som faktiskt går att låsa.

Slutkläm

Artikel 21.2 e är ett uppvaknande för alla som vill göra säkerhet till en efterhandsfråga. Den säger: bygg in säkerhet där den gör mest nytta, när ni väljer, bygger och förvaltar systemet. Då blir riskhantering inte en broms. Den blir ett sätt att slippa panik, sänka kostnaderna över tid och öka tilliten när någon frågar: ‘kan vi lita på det här?’. Ett lås som fungerar i vardagen är inte glamour. Det är frihet.