Informationssäkerhetspolicy: vad lagen faktiskt kräver av den

2 kap. 3 § kräver lämpliga och proportionella tekniska, driftsrelaterade och organisatoriska åtgärder, och räknar sedan upp tio områden som åtgärderna ska omfatta. Punkt 1 avser strategier för riskanalys och för nätverks- och informationssystemens säkerhet.

Det som lämnas öppet är formen. Det finns inget krav på ett visst dokument, ingen föreskriven struktur, ingen obligatorisk rubriklista och inget krav på en viss standard. Det som inte lämnas öppet är att arbetssättet ska finnas och att åtgärderna ska vara försvarbara.

Öppenheten är därför inte en lättnad. Om det inte finns en angiven nivå att uppfylla kan ni heller inte visa att ni uppfyllt den, utan får i stället visa hur ni resonerat. Policyn är det naturliga stället att göra det synligt.

Verksamhetsutövare ska vidta lämpliga och proportionella tekniska, driftsrelaterade och organisatoriska åtgärder för att skydda nätverks- och informationssystem.

Skillnaden mellan en policy som fungerar som bevis och en som inte gör det ligger sällan i längden. Den ligger i om det går att avgöra vem som bestämt vad, när, och på vilken grund.

Fyra uppgifter räcker långt: vad som beslutats, vem som äger beslutet, vilken bedömning det vilar på, och när det ska omprövas. Var och en är trivial att skriva ned i förväg och besvärlig att rekonstruera i efterhand.

Det som väger tyngst i praktiken är den fjärde. Ett omprövningsdatum som passerat utan att något hänt är en svaghet, men ett dokument utan omprövningsdatum är svårare att försvara, eftersom det då inte går att avgöra om innehållet är avsett att gälla eller bara aldrig togs bort.

Det första är att policyn gäller allt. Ett dokument som säger att organisationen ska ha ett systematiskt informationssäkerhetsarbete och skydda sina tillgångar är svårt att invända mot och lika svårt att pröva. Den intressanta uppgiften är vad ni valt bort och varför, eftersom det är där proportionaliteten blir synlig.

Det andra är att policyn saknar spår till riskanalysen. Punkt 1 nämner riskanalys och systemsäkerhet i samma andetag, vilket är en antydan om att de hör ihop. En policy vars val inte går att spåra till en post i riskregistret beskriver preferenser snarare än bedömningar.

Det tredje är att ägarskapet är en funktionsbeteckning utan person bakom. Det hänger ihop med 2 kap. 4 §, som kräver att personer i ledningen genomgår utbildning om säkerhetsåtgärder. Kravet på utbildning förutsätter att någon faktiskt bär ansvaret, och en policy som inte namnger den nivån gör det svårt att visa att skyldigheten fullgjorts.

ISO/IEC 27001 är inget lagkrav och en certifiering ger ingen presumtion om efterlevnad. Standarden producerar däremot ungefär de artefakter som efterfrågas: omfattningsbeskrivning, riskregister, uttalanden om tillämplighet och en beslutad policy med ägare och revisionsintervall.

Det praktiska rådet för den som redan arbetar mot standarden är att inte skriva en separat policy för lagen, utan att komplettera den befintliga med hänvisningar till lagrummen. En bilaga som kopplar varje avsnitt till punkterna i 2 kap. 3 § gör kopplingen synlig utan att duplicera innehåll.

Kom också ihåg föreskriftslagret. Post- och telestyrelsen får meddela föreskrifter om säkerhetsåtgärder och Försvarets radioanstalt om bland annat utbildning och säkerhetsgranskningar. Ange i policyn vilken version av vilken föreskrift den skrevs mot.

Kravet på säkerhet i leverantörskedjan gör att verksamheter som omfattas måste bedöma sina leverantörer. Det första de ber om är nästan alltid policyn, eftersom den är det enda dokument som går att begära utan att fråga om känsliga detaljer.

Det gör policyn till ett dokument med två läsare. Den ena är tillsynsmyndigheten, som vill se att en avvägning gjorts. Den andra är er kunds inköps- eller säkerhetsfunktion, som vill kunna bocka av en rad i sin egen bedömning.

De två behoven krockar sällan, men de har olika krav på vad som får stå. Ett vanligt grepp är att hålla policyn på en nivå som går att dela utan förbehåll och lägga det som inte bör lämna organisationen i underliggande instruktioner som policyn hänvisar till.

En policy som ingen kan förklara är svår att åberopa. Frågan vid en granskning är sällan vad som står i dokumentet, utan varför just det står där, och den frågan går bara att besvara av någon som var med när valet gjordes.

Placera därför ägarskapet på en namngiven nivå och se till att den nivån faktiskt gått igenom innehållet. Det hänger direkt ihop med utbildningskravet i 2 kap. 4 §: ledningen ska genomgå utbildning om säkerhetsåtgärder, och policyn är den naturliga sammanfattningen av vilka åtgärder som beslutats.

Ett enkelt test är att fråga den som äger dokumentet vad ni valt att inte göra och varför. Går det svaret inte att ge är avgränsningarna inte förankrade, oavsett vad som står skrivet.

Det som gör policyer inaktuella är sällan att omvärlden ändras dramatiskt, utan att organisationen gör många små förändringar som ingen kopplar tillbaka till dokumentet. Ett nytt system, en ny leverantör, en flytt av data.

En billig motåtgärd är att koppla policyn till de beslutsflöden som redan finns. Om er förändringshantering redan har ett steg för säkerhetsbedömning, lägg till frågan om förändringen påverkar något som står i policyn. De flesta gånger blir svaret nej, och de gånger det blir ja har ni fångat det i tid.

Notera också vilken version av vilken föreskrift policyn skrevs mot. Post- och telestyrelsen får meddela föreskrifter om säkerhetsåtgärder och Försvarets radioanstalt om bland annat utbildning och säkerhetsgranskningar, och en ändring där kan göra ett avsnitt inaktuellt utan att något i er verksamhet förändrats.