Varje seriöst ramverk för cybersäkerhet börjar med samma dokument: en skriftlig informationssäkerhetspolicy (ISSP) som godkänts av ledningen. NIS2 nämner den först bland riskhanteringsåtgärderna i artikel 21, och ISO/IEC 27001 gör den till ett krav i punkt 5.2. Security Policy Express leder ett europeiskt småföretag genom en guidad digital workshop och tar fram en strukturerad första version i företagets eget namn: ett arbetsutkast som era rådgivare granskar, inte juridisk rådgivning.
Svaret på en minut, för en VD som inte är IT-specialist.
En informationssäkerhetspolicy (ofta förkortad ISSP, eller PSSI på franska) är det dokument där ledningen skriftligen anger hur företaget skyddar sin information och sina IT-system, vem som ansvarar för vad och vilka regler alla måste följa. Den är kort överst (en policyförklaring undertecknad av ledningen) och mer detaljerad under (regler för specifika områden och operativa rutiner). Den är ingen teknisk handbok: den är ett ledningsbeslut, nedskrivet, som resten av ert säkerhetsarbete kan hänvisa till.
ISO/IEC 27001 lägger policyn på ”den högsta ledningen” (top management), och NIS2 artikel 20 kräver att ledningsorganen för berörda entiteter godkänner åtgärderna för riskhantering inom cybersäkerhet och övervakar deras genomförande. Er IT-leverantör kan hjälpa till att skriva den, men bara ledningen kan äga den.
Källor: direktiv (EU) 2022/2555, art. 20 · ISO/IEC 27001:2022, punkt 5God praxis skiljer på tre nivåer. Policyn anger principer och ansvar. Specifika policyer (åtkomstkontroll, säkerhetskopiering, kryptering, leverantörer ...) översätter dem per område. Rutiner beskriver vem som gör vad, steg för steg, när något inträffar. ISO/IEC 27001 kontroll 5.1 nämner uttryckligen både policyn och de specifika policyerna.
Källa: ISO/IEC 27001:2022, bilaga A, kontroll 5.1Ingen europeisk text föreskriver en enda mall. NIS2 artikel 21(1) kräver åtgärder som är ”lämpliga och proportionella”, med hänsyn till entitetens exponering för risker, dess storlek samt sannolikheten och allvarlighetsgraden hos incidenter. En tillverkare med 40 anställda och ett sjukhus skriver inte samma policy, och ska inte göra det.
Källa: direktiv (EU) 2022/2555, art. 21(1)En policy som skrivs en gång och läggs i en pärm skyddar ingenting. Ramverken förutsätter att den kommuniceras till personalen, bekräftas och granskas med planerade intervall och efter väsentliga förändringar. Därför bör er policy redan från början innehålla sin egen granskningscykel, sin ägare och sin versionshistorik.
Källa: ISO/IEC 27001:2022, punkt 5.2 och kontroll 5.1De flesta små och medelstora företag tillämpar redan vissa säkerhetsregler. Det som oftast saknas är den skriftliga, godkända och sammanhängande versionen som en tillsynsmyndighet, en revisor, ett försäkringsbolag eller en stor kund faktiskt kan läsa.
NIS2 utvidgar EU:s cybersäkerhetsregler till många medelstora företag inom sektorer som tillverkning, livsmedel, avfallshantering, transport eller digitala tjänster. För berörda entiteter är ”policyer för riskanalys och säkerhet i informationssystem” den första åtgärden i artikel 21(2).
NIS2 artikel 21(2)(d) kräver att berörda entiteter hanterar säkerheten i leveranskedjan, inklusive säkerhetsaspekter i relationerna med direkta leverantörer. Även om ni inte omfattas kan era större kunder be er visa en skriftlig säkerhetspolicy i sina leverantörsenkäter.
Att skriva en policy innebär att besvara många frågor samtidigt: vilka är våra kritiska tillgångar, vem fattar besluten, vad gör vi vid en ransomwareattack, hur länge sparar vi säkerhetskopior? Utan struktur brukar arbetet skjutas upp, kvartal efter kvartal.
Nedladdade mallar beskriver ofta en organisation med en informationssäkerhetschef, ett security operations center och en egen budget. Ett dokument som inte stämmer med verkligheten är värre än inget alls: det kommer inte att tillämpas, och en revisor ser skillnaden mellan papper och praktik.
Samma dokument besvarar flera regelverk samtidigt. Här är vad vart och ett faktiskt säger, med en länk till den officiella källan. Nationella införlivanden kan lägga till detaljer.
Väsentliga och viktiga entiteter ska vidta ”lämpliga och proportionella tekniska, operativa och organisatoriska åtgärder” för att hantera riskerna för cybersäkerhet, utifrån ett allriskperspektiv. Listan i artikel 21(2) inleds med ”a) policyer för riskanalys och säkerhet i informationssystem”. Artikel 20 tillägger att ledningsorganen godkänner åtgärderna, övervakar genomförandet och följer utbildningen.
Punkt 5.2 kräver att den högsta ledningen fastställer en informationssäkerhetspolicy som är lämplig för organisationens syfte, utgör en ram för säkerhetsmål och innehåller åtaganden att uppfylla tillämpliga krav och att fortlöpande förbättra systemet. Den ska vara dokumenterad, kommuniceras internt och göras tillgänglig för berörda parter i lämplig omfattning. Bilaga A, kontroll 5.1, utvidgar detta till specifika policyer som godkänns, publiceras, bekräftas och granskas.
Artikel 24(2) anger att den personuppgiftsansvariges åtgärder, när det är proportionerligt i förhållande till behandlingen, inkluderar ”införande av lämpliga dataskyddspolicyer”. Artikel 32 kräver lämpliga tekniska och organisatoriska åtgärder för att säkerställa en säkerhetsnivå som är lämplig i förhållande till risken. En säkerhetspolicy är den naturliga platsen att dokumentera dessa åtgärder.
För vissa digitala entiteter (till exempel leverantörer av molntjänster, datacenter och hanterade tjänster) antog kommissionen detaljerade tekniska krav och metodkrav. Dess bilaga inleds med en ”policy för säkerheten i nätverks- och informationssystem” och beskriver hur den godkänns, dokumenteras och granskas. Även om ert företag inte är en sådan entitetstyp är bilagan en användbar, offentlig referens för att strukturera en policy.
För finansiella enheter kräver DORA att de utvecklar och dokumenterar en informationssäkerhetspolicy som definierar regler för att skydda tillgänglighet, äkthet, integritet och konfidentialitet för data, informationstillgångar och IKT-tillgångar. Om ni är IKT-leverantör till en bank eller ett försäkringsbolag, räkna med att kunden frågar hur er egen policy förhåller sig till deras.
Nationella cybersäkerhetsmyndigheter publicerar kostnadsfri vägledning som en policy kan bygga på. I Frankrike anger ANSSI:s guide om IT-hygien 42 grundläggande åtgärder för dem som ansvarar för en organisations informationssystem. ENISA, EU:s byrå för cybersäkerhet, publicerar vägledning som stöder genomförandet av NIS2 i hela unionen.
Artikel 21(2) i NIS2 listar tio minimiåtgärder. Led a är själva policyn, men en välbyggd policy är också det ställe där de övriga nio får sin ägare, sin regel och sin rutin. Så här strukturerar vi det genererade dokumentet.
Policyförklaringen, omfattningen, rollerna och metoden för att identifiera och bedöma risker. Detta är dokumentets ryggrad.
En rutin för incidenthantering: upptäckt, klassificering, eskalering, inneslutning, anmälan och lärdomar.
Hantering av säkerhetskopior, katastrofåterställning och krishantering, så som direktivet formulerar det: vem som beslutar, vad som startar först, hur ofta säkerhetskopior testas.
Regler för att välja, avtala och följa upp IT-leverantörer och tjänsteleverantörer, inklusive de säkerhetsklausuler ni förväntar er av dem.
Hur nya system väljs och konfigureras, hur uppdateringar tillämpas och hur sårbarheter hanteras och redovisas.
Policyer och rutiner för att kontrollera att åtgärderna fungerar: nyckeltal, interna granskningar, övningar och ledningens översyn.
De dagliga reglerna (lösenord, uppdateringar, medvetenhet om nätfiske) och en utbildningsplan, även för ledningen, så som artikel 20(2) kräver för ledningsorganen.
När data måste krypteras (bärbara datorer, säkerhetskopior, överföringar), vilka protokoll som är godkända och vem som hanterar nycklarna.
Anställning, byte av roll och avslut; vem som får vilken åtkomst och vem som godkänner den; en förteckning över tillgångar med deras ägare.
Var multifaktor- eller kontinuerlig autentisering krävs, och hur röst, video, text och nödkommunikation säkras.
Hänvisningarna till ISO/IEC 27001 är vägledande motsvarigheter som vi tagit fram för att hjälpa er att navigera, inte en officiell översikt publicerad av ISO eller Europeiska kommissionen. Källa för de tio åtgärderna: direktiv (EU) 2022/2555, art. 21(2).
Det genererade dokumentet följer en struktur som en revisor, ett försäkringsbolag eller en kund känner igen. Varje kapitel fylls i utifrån de svar ni ger i workshopen, så att det beskriver ert företag och inte ett påhittat exempel.
Ledningens åtagande, i några stycken, undertecknat och daterat.
Vem som beslutar, vem som genomför, vem som kontrollerar, även när IT är outsourcad.
Ett enkelt och upprepbart sätt att identifiera, bedöma och hantera risker.
Att veta vad man skyddar innan man bestämmer hur.
Vem som får åtkomst till vad, och hur detta bevisas.
Den tekniska grunden, skriven på ett begripligt språk.
Var kryptering krävs och hur den hanteras.
Säkerhet i relationerna med IT-leverantörer och molntjänster.
Den mänskliga sidan, från anställning till avgång.
Lokaler, serverrum och utrustning utanför kontoret.
Principerna, som beskrivs i rutinerna nedan.
Hur policyn förblir levande och korrekt.
En policy anger vad som ska ske; en rutin anger vem som gör det, i vilken ordning och med vilken dokumentation. Dessa fyra är de som kunder och revisorer oftast ber att få se, och de som betyder mest den dag något går fel.
Från första larmet till slutrapporten: hur personalen rapporterar en misstänkt händelse, vem som klassificerar den, vem som isolerar de berörda systemen, vem som kontaktar er IT-leverantör, ert försäkringsbolag och myndigheterna, och hur bevis säkras.
Hur ett konto begärs, godkänns, skapas, ändras och tas bort. Rutinen omfattar nyanställningar, byte av roll och avslut, administratörskonton, delade konton och tjänstekonton, samt den periodiska granskningen där en chef bekräftar att varje person fortfarande behöver sin åtkomst.
Hur en ändring i ett produktionssystem (en ny applikation, en brandväggsregel, en större uppdatering) beskrivs, bedöms för risk, godkänns, testas, genomförs och vid behov återställs. I ett litet företag kan detta vara lätt: ett kort formulär och en logg räcker, under förutsättning att de finns och används.
Vad som säkerhetskopieras, hur ofta, var, hur länge, och framför allt hur återställningen testas. Rutinen kopplar säkerhetskopior till återställningsmål per kritisk verksamhet och beskriver krisorganisationen: vem som beslutar, vem som kommunicerar, vilka system som startar först.
Informationssäkerhetspolicyn är skriven för ledning och IT. Användarpolicyn (AUP, acceptable use policy) är skriven för alla andra: den korta, lättlästa uppsättning regler som varje anställd, tillfällig medarbetare eller konsult godkänner innan de använder företagets IT.
Användning av konton och lösenord, e-post och meddelanden, internetåtkomst, privat användning som tolereras eller inte, mobila enheter och distansarbete, flyttbara medier, molntjänster och verktyg för generativ AI, konfidentialitet, rapportering av incidenter, samt vad företaget får övervaka och varför.
ISO/IEC 27001 kontroll 5.10 kräver att regler för acceptabel användning av information och andra tillhörande tillgångar identifieras, dokumenteras och införs. Genom att hålla dessa regler i en separat bilaga blir de lättare att läsa, underteckna, uppdatera och bifoga till anställningsavtal.
När AUP nämner loggning eller övervakning av personalens aktivitet gäller dataskyddslagstiftningen: anställda måste informeras (GDPR art. 13), och medlemsstaterna kan anta mer specifika regler för anställningsförhållanden (GDPR art. 88). Dataskyddsmyndigheter, till exempel den franska CNIL, publicerar vägledning om vad som är acceptabelt.
Att göra AUP bindande för anställda kan kräva nationella formaliteter. I Frankrike till exempel (bekräfta med er rådgivare mot Code du travail, den franska arbetsrättslagstiftningen) brukar regler av det här slaget bifogas det interna ordningsreglerna (règlement intérieur), som följer ett förfarande fastställt i Code du travail, inklusive samråd med personalrepresentanterna. Kontrollera reglerna i ert land med er rådgivare.
Källor: ISO/IEC 27001:2022, A.5.10 · förordning (EU) 2016/679, art. 13, 88 · CNIL · Légifrance, Code du travail (franska arbetsrättslagstiftningen), art. L1321-4 och L1321-5.
En policy beskriver ett företag som förändras: nya medarbetare, ny programvara, nya leverantörer, nya hot. De ramverk vi hänvisar till förutsätter i allmänhet att den hålls uppdaterad. Det genererade dokumentet innehåller sin egen granskningskalender, ägare och versionstabell.
Den första versionen godkänns av ledningen, dateras och versionshanteras. Enligt NIS2 art. 20(1) godkänner ledningsorganen för berörda entiteter åtgärderna för riskhantering inom cybersäkerhet; enligt ISO/IEC 27001 punkt 5.2 fastställer den högsta ledningen policyn.
Policyn publiceras internt; användarpolicyn bekräftas av varje användare. ISO/IEC 27001 kontroll 5.1 förutsätter att policyer kommuniceras till och bekräftas av berörd personal och berörda parter.
ISO/IEC 27001 kontroll 5.1 kräver granskning med planerade intervall och vid väsentliga förändringar. En årlig granskning är ett förnuftigt utgångsläge för ett småföretag; kommissionens genomförandeförordning (EU) 2024/2690 reglerar också översynen av policyn för de digitala entitetstyper den omfattar.
En allvarlig incident, en fusion, en ny anläggning, en flytt till molnet eller ny lagstiftning är alla skäl att öppna dokumentet igen utan att vänta på årsdagen. Lärdomarna från incidenter förs in i nästa version.
Versionstabell, godkännandelogg, lista över ändringar, bekräftelser. Den dag en revisor, ett försäkringsbolag eller en kund frågar är just denna historik det som visar att policyn tillämpas och inte bara är skriven. ISO/IEC 27001 punkt 7.5 styr denna dokumenterade information.
Security Policy Express är utformat som ett självbetjäningsverktyg. Ni behåller kontrollen över innehållet; verktyget tillhandahåller strukturen, frågorna och hänvisningarna.
Ett kort test frågar om er bransch, storlek, verksamhet och kunder, och talar om för er om NIS2 sannolikt gäller för er, vilka andra texter som kan vara relevanta och vilka delar av policyn som är viktigast i er situation. Det hänvisar er till de officiella verktygen hos er nationella myndighet för ett slutgiltigt svar.
Ni besvarar, med egna ord, en serie guidade frågor kapitel för kapitel: er organisation, era kritiska verksamheter, er IT-leverantör, era säkerhetskopior, hur ni hanterar avslut, vad ni skulle göra vid en ransomwareattack. Varje fråga förklarar varför den ställs och vilken artikel eller kontroll den hör till. Ni kan avbryta och återuppta när som helst.
Verktyget tar fram policyn, de fyra rutinerna och användarpolicyn som bilaga i ert företags namn, utifrån era svar. Där ett svar saknas anger dokumentet det uttryckligen i stället för att fylla luckan med generisk text. Resultatet är ett arbetsutkast som ska granskas och godkännas av era egna rådgivare (jurist, IT-leverantör, dataskyddsombud) innan ledningen godkänner det.
Om ni vill ha hjälp att granska era svar kritiskt, anpassa dokumentet till ett specifikt sammanhang eller förbereda en revision kan ni begära stöd från en partnerkonsult. Detta steg är valfritt: självbetjäningsvägen är komplett utan det.
Viktigt: det genererade dokumentet är ett arbetsunderlag. Det utgör inte juridisk rådgivning och innebär inte i sig att ert företag uppfyller kraven i NIS2, ISO/IEC 27001, GDPR eller någon nationell lag. Efterlevnad beror på vad ni faktiskt genomför och förblir ert ansvar.
Tre byggstenar, genererade tillsammans utifrån samma workshop. Tillgänglighet och villkor meddelas vid lansering.
Kärndokumentet, undertecknat av ledningen.
Det som gör policyn operativ.
För att hitta rätt i texterna.
Två situationer bör inte förväxlas: en rättslig skyldighet för företag inom NIS2:s (eller DORA:s) tillämpningsområde, och en starkt rekommenderad god praxis för alla andra.
NIS2 gäller i allmänhet för offentliga eller privata entiteter av ett slag som anges i dess bilaga I eller II och som är medelstora företag eller överskrider taken för medelstora företag, enligt kommissionens rekommendation 2003/361/EG (art. 2(1)). Vissa entitetstyper omfattas oavsett storlek (art. 2(2)). Entiteterna klassificeras sedan som ”väsentliga” eller ”viktiga” (art. 3), vilket påverkar tillsyn och sanktioner, men båda ska tillämpa artikel 21.
Bilaga I (sektorer av hög kritikalitet): energi, transport, bank, infrastruktur för finansmarknader, hälso- och sjukvård, dricksvatten, avloppsvatten, digital infrastruktur, hantering av IKT-tjänster (företag till företag), offentlig förvaltning och rymd. Bilaga II (andra kritiska sektorer): post- och budtjänster, avfallshantering, kemikalier, livsmedel, tillverkning (inklusive medicintekniska produkter, elektronik, elektrisk utrustning, maskiner och fordon), digitala leverantörer och forskning.
NIS2 är ett direktiv: medlemsstaterna skulle införliva det senast den 17 oktober 2024 och tillämpa åtgärderna från den 18 oktober 2024 (art. 41). Införlivandets status och detaljer skiljer sig mellan länderna, och nationell lag kan precisera innehållet i åtgärderna. Kontrollera alltid lagen och de officiella behörighetsverktygen i ert land.
Utanför dessa tillämpningsområden kräver ingen allmän europeisk lag att ett småföretag antar ett dokument som kallas ”informationssäkerhetspolicy”. Men GDPR gäller för nästan alla företag, kunder frågar allt oftare leverantörer om säkerhet, och en skriftlig policy är första steget i varje erkänt ramverk. Det är en klok försiktighetsåtgärd, inte ett rättsligt krav.
Källor: direktiv (EU) 2022/2555, art. 2, 3, 41 och bilagorna I och II · kommissionens rekommendation 2003/361/EG · Europeiska kommissionen, sida om NIS2-direktivet · Frankrike: ANSSI, sida om NIS 2 (MesServicesCyber).
Varje reglerande eller normativt påstående ovan hänvisar till en av dessa källor. Länkarna går till den officiella utgivaren.
Denna sida tillhandahålls i informationssyfte. Den utgör inte juridisk rådgivning. Texterna hänvisas till i den version som publicerats på EUR-Lex; nationella införlivanden och myndigheters vägledning kan tillföra ytterligare krav.
Självbetjäningsverktyget är under förberedelse. Frågor under tiden: contact@syaga.eu.