Från NIS2 till praktiken – så påverkas din mjukvaruleverantör

NIS2 innebär att cybersäkerhet inte längre enbart är en intern IT-fråga, utan en central del av hur företag väljer, granskar och samarbetar med sina leverantörer. För organisationer som använder programvara från externa aktörer kan kraven därför få konkreta konsekvenser för både avtal, riskbedömningar och säkerhetsrutiner. Mjukvaruleverantörer behöver i sin tur kunna visa hur de identifierar och hanterar cyberrisker, skyddar information och agerar vid incidenter. Det påverkar inte bara leverantörens egen verksamhet, utan även kunder som är beroende av systemen. Här går vi igenom vad NIS2 innebär i praktiken och hur relationen mellan företag och mjukvaruleverantörer kan förändras framöver.

Så påverkar NIS2 kraven på mjukvaruleverantörer

NIS2 förändrar förutsättningarna för hur företag behöver se på sina mjukvaruleverantörer. En central del av regelverket är säkerheten i leveranskedjan, där organisationer ska hantera risker som uppstår genom relationen med externa leverantörer och tjänsteleverantörer. Det innebär att ett företag som omfattas av NIS2 inte längre kan betrakta säkerheten hos en mjukvaruleverantör som en fråga som enbart ligger på leverantörens bord. Kraven behöver i stället vägas in när programvara köps in, används, uppdateras och förvaltas. På så sätt blir leverantörens säkerhetsarbete en del av kundens eget cybersäkerhetsarbete.

Säkerhet blir en del av leverantörsrelationen

För mjukvaruleverantörer innebär utvecklingen att säkerhetsfrågor kan få större betydelse redan innan ett avtal tecknas. Kunder som omfattas av NIS2 behöver kunna bedöma om leverantören har tillräckliga säkerhetsrutiner, hur produkten utvecklas och hur risker hanteras under hela dess livscykel. Det kan exempelvis handla om säkra utvecklingsprocesser, sårbarhetshantering, incidentrutiner och möjligheten att snabbt få tillgång till säkerhetsuppdateringar. Leverantörens cybersäkerhetspraxis och förmåga att uppfylla kundens säkerhetskrav kan därmed få större betydelse när företag väljer vilka system och tjänster de ska använda.

Det innebär inte att alla mjukvaruföretag automatiskt omfattas av exakt samma skyldigheter enligt NIS2. Den direkta regleringen riktar sig mot de verksamheter som faller inom direktivets tillämpningsområde. Däremot kan kraven få en tydlig indirekt effekt på leverantörer som säljer system och tjänster till sådana verksamheter. Om kunden behöver kunna visa att dess leveranskedja är tillräckligt säker, kan leverantören behöva lämna mer information om exempelvis säkerhetsåtgärder, incidenthantering och utvecklingsprocesser. Leverantörens cybersäkerhetsnivå kan därmed bli en konkurrensfaktor i upphandlingar och avtalsförhandlingar.

Avtalen får större betydelse

En annan praktisk konsekvens är att cybersäkerhetskrav i högre grad kan behöva formaliseras i avtal. För verksamheter som omfattas av mer detaljerade säkerhetskrav kan leverantörsavtal behöva reglera exempelvis säkerhetsåtgärder, incidentrapportering och möjligheter till uppföljning. Det innebär att en mjukvaruleverantör kan möta krav på att rapportera incidenter utan onödigt dröjsmål, ge kunden tillgång till relevant dokumentation eller uppfylla särskilda krav på personalens kompetens och säkerhetsmedvetenhet. Kraven kan variera beroende på verksamhetens risknivå, men utvecklingen går tydligt mot mer konkreta säkerhetsvillkor i leverantörsrelationer.

För leverantörer innebär detta att cybersäkerhet behöver hanteras både tekniskt och kommersiellt. Det räcker inte alltid att produkten är säker i praktiken om kunden samtidigt saknar tillräcklig dokumentation för att kunna bedöma och följa upp säkerhetsnivån. Mjukvaruföretag kan därför behöva utveckla tydligare processer för hur säkerhetsinformation presenteras, hur sårbarheter kommuniceras och hur incidenter hanteras tillsammans med kunder. Även frågor om beroenden till underleverantörer och andra externa tjänster kan bli viktigare. NIS2 gör därmed leverantörens säkerhetsarbete till en mer integrerad del av den kommersiella relationen.

Därför blir leverantörsgranskning allt viktigare

När säkerheten i leveranskedjan får större betydelse förändras också hur företag behöver granska sina mjukvaruleverantörer. För en organisation som omfattas av NIS2 handlar det inte bara om att kontrollera om leverantören har en viss certifiering eller kan svara ja på ett säkerhetsformulär. Bedömningen behöver utgå från vilka risker leverantören faktiskt medför för verksamhetens nätverks- och informationssystem. Det gör att leverantörsgranskning behöver bli mer riskbaserad och kopplad till den funktion som programvaran har i verksamheten. Ju mer kritiskt systemet är, desto större anledning finns att ställa detaljerade krav.

Från frågeformulär till riskbedömning

En mjukvaruleverantör kan exempelvis behöva redogöra för hur säker utveckling bedrivs, hur sårbarheter identifieras och hur säkerhetsuppdateringar distribueras. Kunden kan också vilja förstå vilka underleverantörer som används, var data behandlas och hur leverantören agerar vid en incident. Säker utveckling, produktresiliens och förmågan att uppfylla fastställda säkerhetsspecifikationer blir därmed relevanta delar av bedömningen. Det gör att en leverantörsgranskning kan behöva gå betydligt djupare än en generell kontroll av exempelvis informationssäkerhetspolicyer. Fokus flyttas från vad leverantören säger att den gör till hur säkerhetsarbetet faktiskt fungerar.

För mjukvaruleverantören kan detta innebära fler säkerhetsfrågor från kunder och mer omfattande krav på dokumentation. Samtidigt behöver kunderna själva undvika att göra granskningen onödigt omfattande. En riskbaserad modell innebär att informationen som efterfrågas bör stå i proportion till den faktiska risken. Om en programvara hanterar verksamhetskritisk information eller är avgörande för en central process kan kraven behöva vara mer omfattande. För mindre kritiska system kan granskningen vara enklare. Ett sådant arbetssätt minskar den administrativa belastningen samtidigt som resurserna kan koncentreras till de leverantörer som innebär störst risk.

Dokumentation blir ett konkurrensmedel

För leverantörer blir det därför allt viktigare att kunna visa, snarare än enbart beskriva, hur säkerhetsarbetet fungerar. Dokumentation av processer, incidenter, säkerhetsuppdateringar och riskhantering kan göra det enklare att svara på kundernas krav. Även oberoende granskningar och relevanta säkerhetscertifieringar kan få större praktisk betydelse när kunder jämför olika leverantörer. Samtidigt är en certifiering inte automatiskt ett bevis på att alla risker är hanterade. Kunden behöver fortfarande bedöma om leverantörens säkerhetsnivå är lämplig i förhållande till den aktuella tjänsten och dess betydelse för verksamheten.

Granskningen behöver dessutom fortsätta efter att avtalet har skrivits under. Säkerhetsrisker förändras när programvara uppdateras, nya integrationer införs, underleverantörer byts eller verksamheten förändras. NIS2:s fokus på leveranskedjan innebär därför ett behov av löpande uppföljning snarare än en engångskontroll vid inköp. För mjukvaruleverantören kan det innebära återkommande säkerhetsbedömningar, uppdaterade underlag och krav på att snabbt kunna informera kunder om förändrade risker. Leverantörsrelationen blir därmed mer dynamisk, där säkerhet behöver följas upp under hela produktens eller tjänstens livscykel.

Från säkerhetskrav till konkreta åtgärder

Att gå från NIS2:s krav till praktiskt säkerhetsarbete handlar i stor utsträckning om att göra cybersäkerhet mätbar och integrerad i den dagliga verksamheten. För en mjukvaruleverantör kan det innebära att säkerhetsfrågor behöver byggas in i hela kedjan, från utveckling och testning till drift, support och avveckling. Samtidigt behöver leverantören kunna hantera kundernas krav utan att skapa processer som enbart existerar för dokumentationens skull. Målet bör vara att säkerhetskraven faktiskt minskar riskerna, samtidigt som organisationen kan visa kunder och andra intressenter hur arbetet bedrivs.

Säkerhet genom hela livscykeln

Ett viktigt område är säker utveckling. Mjukvaruleverantören behöver ha rutiner för att identifiera och hantera sårbarheter innan och efter att en produkt har lanserats. Det kan exempelvis innebära kodgranskning, tester, hantering av beroenden, säkerhetsuppdateringar och etablerade processer för sårbarhetsrapportering. NIS2 lyfter säkerhet vid anskaffning, utveckling och underhåll av nätverks- och informationssystem, inklusive hantering och rapportering av sårbarheter. För leverantörer innebär det att säkerhetsarbetet behöver omfatta mer än den färdiga produkten. Även utvecklingsprocessen och den fortsatta förvaltningen blir relevanta delar av säkerhetsbilden.

Incidenthantering är ett annat centralt område. Om en sårbarhet eller incident påverkar en kunds system kan tiden från upptäckt till information vara avgörande. Därför behöver leverantören ha tydliga kontaktvägar, ansvarsfördelning och processer för att bedöma och kommunicera incidenter. Avtalskrav kan dessutom ange när och hur kunden ska informeras. För ett mjukvaruföretag är det därför relevant att säkerställa att support, drift, utveckling och juridik vet hur en allvarlig säkerhetshändelse ska hanteras. En tekniskt välfungerande produkt behöver kompletteras med organisatorisk förmåga att agera när något ändå går fel.

Gör kraven operativa

För att kraven ska fungera i praktiken behöver de översättas till konkreta interna rutiner. Det kan handla om att dokumentera ansvar, införa regelbundna riskbedömningar, följa upp underleverantörer och säkerställa att säkerhetsuppdateringar kan distribueras under produktens hela livslängd. Det är också relevant att identifiera vilka delar av den egna leveranskedjan som är mest kritiska. NIS2 betonar säkerheten i relationerna med direkta leverantörer och tjänsteleverantörer, vilket innebär att företaget behöver förstå vilka externa beroenden som kan påverka dess verksamhet. Då blir det lättare att prioritera rätt säkerhetsåtgärder.

För en mjukvaruleverantör kan ett praktiskt arbete därför börja med att kartlägga vilka kunder och tjänster som har höga säkerhetskrav. Därefter kan leverantören identifiera vilka säkerhetskontroller, avtalskrav och dokumentationsunderlag som behöver finnas på plats. Det är också viktigt att se över beroenden till molntjänster, bibliotek, externa driftmiljöer och andra komponenter som kan påverka produktens säkerhet. När sådana beroenden blir tydliga blir det lättare att bedöma var riskerna finns och vilka åtgärder som ger störst effekt. På så sätt blir NIS2 en struktur för ett mer systematiskt säkerhetsarbete, snarare än enbart ytterligare ett regelverk att förhålla sig till.