Skriv en policy människor faktiskt läser
En steg-för-steg-guide för att bygga om en säkerhetspolicy från byråkratiskt regeldokument till användbar text.
En informationssäkerhetspolicy kommer förmodligen aldrig bli organisationens mest lästa dokument, men det behöver heller inte vara målet. Det viktigare är att den går att begripa när någon faktiskt öppnar den, att kraven går enkelt att omsätta i arbetet, och att det är lätt att hitta tillbaka när en konkret fråga uppstår.
Det är en helt annan ambition än att bara göra policyn kort. En tvåsidig policy kan vara nästan oanvändbar om den är full av abstrakta formuleringar och ett överdrivet byråkratiskt språk, medan ett något längre dokument kan funka bra om det har en tydlig struktur och hjälper läsaren förstå vad som förväntas. Problemet med många policyer är därför inte bara antalet ord, utan att de försöker vara styrdokument, juridisk dokumentation, handbok, utbildningsmaterial och revisionsbevis på samma gång.
Aktuell vägledning från brittiska NCSC (National Cyber Security Center) beskriver dessutom en annan balans ganska träffsäkert. Alltför detaljerade säkerhetsregler riskerar att bli otympliga och snabbt inaktuella, medan för vaga regler lämnar människor utan tillräckligt stöd. NCSC rekommenderar därför bl.a. att regler ska vara begripliga, lätta att hitta och användbara i det verkliga arbetet, och att organisationer faktiskt testar om reglerna fyller en meningsfull säkerhetsfunktion.
Den här guiden försöker bryta ner hur man skriver en begriplig policy som medarbetare har lättare att agera på.
Introduktionen sätter tonen
Börja med att själv formulera vad läsaren absolut behöver få med sig från policyn.
Om någon har läst dokumentet och en månad senare bara minns tre, fyra eller fem saker, vilka behöver de vara? Eller om, gud förbjude, någon bara läser början av dokumentet och sen tröttnar halvvägs. Vad är viktigast?
Vad du än kommer fram till så är det policyns kärna, och det är viktigt att den är tydlig för dig innan resten av dokumentet börjar växa runt den. Kärnan kan skrivas som några enstaka rader, eller som en punktlista.
Som redaktionellt filter när du väl skriver bör du fråga vilken funktion det fyller när ett nytt stycke eller krav planeras. Hjälper det läsaren förstå ett centralt krav, agera rätt eller hantera en situation där regeln blir svår att använda? Om inte kanske informationen hör hemma i en instruktion, ett bakgrundsdokument eller ingenstans alls.
Vill man framhäva en viss känsla är starten bra även för det; kanske en sense of urgency som förklarar att hemmaarbete var roten till tre av fem incidenter förra året, och därför är DU som medarbetare så himla viktig.
Att bestämma de viktigaste punkterna tidigt hjälper dessutom senare när policyn ska kommuniceras. De kommer sannolikt bli samma saker som ska lyftas i mejlet, intranätstexten eller introduktionen som följer med policyn när den publiceras.
Var tydlig med vad policyn faktiskt ska göra
Vi vet alla att en policy är ett styrande dokument som ska beskriva vad som gäller, för vem och inom vilka gränser. Men vad den inte behöver göra är att samtidigt innehålla allt en person nånsin kan behöva veta om ämnet.
Det låter självklart, men många policyer blir långa och komplexa därför att varje möjlig fråga försöker lösas i samma dokument, eller man försöker få in för mycket bakgrundsinformation eller förklaringar.
Ett krav på att information ska lagras i en godkänd miljö följs av instruktioner om hur systemet används, lite teknisk bakgrund, skärmbilder och undantagsfall. I värsta fall ändras verktyget några månader senare och halva policyn är gammal trots att själva säkerhetskravet fortfarande är relevant. I det fallet har du skaffat dig en garanti för att folk ska tappa intresset och sluta läsa.
En lösning på det här kan vara att hålla isär policy och instruktion. Policyn bör säga vad som gäller och ge tillräckligt med sammanhang för att kravet ska vara begripligt, medan instruktionen kan beskriva exakt hur en viss uppgift utförs. Om verktyg, menyer eller arbetsflöden ändras kan instruktionen då uppdateras utan att hela styrdokumentet behöver göras om.
Skriv krav som går att omsätta i en handling
Informationssäkerhetspolicies tenderar ibland att ha en särskild förkärlek för formuleringar som låter bra tills man försöker följa dem. ”Information ska hanteras säkert”, ”användare ska iaktta försiktighet” eller ”medarbetare ansvarar för korrekt informationshantering” är svåra att invända mot, men berättar väldigt lite om vad personen faktiskt förväntas göra.
Svensk forskning från 2025 har särskilt tittat på det forskarna kallar "actionable advice", alltså instruktioner i informationssäkerhetspolicyer som faktiskt går att agera på. Studien bygger bl.a. på analys av 47 policyer från svenska offentliga organisationer och definierar handlingsbara råd som formuleringar som tydliggör vilken uppgift någon ska eller inte ska utföra och, när det behövs, hur uppgiften ska genomföras.
Det är en användbar princip även utan forsknings-lingo. ”Använd bara godkända tjänster i lista X (länkad) för kunduppgifter” ger mottagaren betydligt mer att arbeta med än ”kundinformation ska hanteras i enlighet med organisationens säkerhetskrav”.
Du behöver inte beskriva varje knapptryckning, men läsaren ska så långt det är möjligt kunna förstå vilket beteende policyn kräver.
Skilj tydligt mellan krav och råd
En annan vanlig källa till osäkerhet är när samma dokument blandar sånt som är obligatoriskt med sånt som bara är ganska bra att göra. ”Ska”, ”bör”, ”rekommenderas” och ”förväntas” börjar glida ihop och till sist får läsaren själv avgöra hur starkt varje påstående är.
Om något är ett krav ska det framgå, och om en formulering är vägledning och det finns utrymme för professionellt omdöme ska även det vara tydligt. NCSC pekar uttryckligen på vikten av att människor kan skilja mellan regler som måste följas och riktlinjer som ska hjälpa dem göra bra bedömningar.
Använd exempel där abstrakta regler annars blir svåra
En policy blir ofta betydligt begripligare om vissa regler får ett konkret sammanhang. Det betyder inte att varje krav behöver följas av ett scenario, men där människor regelbundet behöver översätta ett abstrakt begrepp kan några exempel göra mycket.
Om policyn använder begreppet ”känslig information” kan det vara värdefullt att nämna några typer av material som mottagaren faktiskt möter. Om regeln handlar om extern delning kan en kort situation med en leverantör, konsult eller kund göra det tydligare när regeln blir relevant.
Vill du göra det här målgruppsanpassat kan du med fördel hänvisa till instruktioner som biläggs med exempel anpassat för olika avdelningen, länder, eller vanliga system.
Poängen är förstås inte att beskriva alla tänkbara situationer - använd dem snarare där risken för feltolkning är störst eller där du vet att människor brukar behöva hjälp med gränsdragningen.
Det är också här det kan vara klokt att involvera människorna som faktiskt gör jobbet, för att begripa hur de påverkar verkliga arbetsflöden.
Skriv för att policyn ska gå att använda som uppslagsverk
Jag vet att vi alla hoppas att policyn läser från början till slutet, men så ser det förstås inte alltid ut. Ibland orkar man bara en bit i början och skummar resten, och ibland besöker man den när man har konkreta frågor; ”Får jag använda den här tjänsten?” ”Vad gäller när jag skickar information till en kund?”
Strukturen bör fungera för den läsningen också.
Ett bra sätt att hantera det här på är att tänka till rejält på rubriksättningen. Att ex. tänka till på rubriker som beskriver situationer och handlingar är ofta lättare att hitta tillbaka till än interna styrningsbegrepp. ”När du delar information externt” eller "Rapportering av incidenter" är båda exempel på tydlig rubriksättning.
Ta en särskild funderare över vad som är det troligaste människor kommer leta efter i policyn, och se till att det är särskilt lätt att hitta.
En modern policy behöver på det sättet fungera mer som ett användbart referensdokument och mindre som en text människor förväntas memorera.
Gör det enkelt att fråga, rapportera och begära undantag
Policyer är oftast skrivna för normalsituationen, men tyvärr har verkligheten har en dålig vana att innehålla undantag.
Om policyn säger att en viss tjänst inte får användas men den godkända lösningen inte fungerar för ett viktigt kundarbete så behöver medarbetaren veta vad nästa steg är. Om någon är osäker på hur en regel ska tolkas bör det finnas en tydlig kontaktväg för att du sen ska slippa hantera kollegor som hittat egna lösningar (shadow IT/AI).
Provtryck reglerna
När policyn är nästan färdig brukar den inte sällan skickas runt för granskning. Gör då inte misstaget att köra texten genom några utvalda chefer och juristerna.
Ta några av de centrala reglerna och testa dem tillsammans med människor som kommer omfattas av dem, och be marknadsavdelningen bedöma det språkliga.
NCSC går ganska långt i sina rekommendationer här och säger att organisationer bör testa varje säkerhetsregel för att se om den faktiskt bidrar meningsfullt till säkerheten, går att använda och passar organisationens syfte.
Rensa lika aktivt som du lägger till
Jag gillar att jämföra policies med garderober - för varje plagg du köper bör du också se om det är något som ska flytta ut. Samma tänk kan man applicera på policyarbete för att undvika en tegelsten efter några år, när den har byggts på efter incidenter, revisioner, och i allmänhet nya förutsättningar.
Finns samma krav på flera ställen, uttrycka lite olika? Beskriver policyn ett system eller en situation som inte längre är aktuell? Finns en regel kvar mest därför att ingen vågat fråga varför den behövs?
Att hålla en policy kort nog för att vara användbar handlar därför minst lika mycket om att redigera bort som att skriva koncist från början.
Leverera inte policyn ensam
När dokumentet är beslutat må policyn vara klar, men kommunikationsjobbet är det inte.
Att lägga policyn på intranätet och skicka ut en länk innebär fortfarande att varje mottagare själv måste förstå vad som är nytt, vad som är viktigast, eller om något i det egna arbetet behöver förändras. Därför är det klokt att redan från början räkna med att policyn ska levereras tillsammans med ett annat mer kommunikativt lager som hjälper människor in i den.
Det kan vara en text eller en filmsnutt och kan handla om det viktigaste i policyn, varför man har tagit fram den/förändrat den förra, eller peka på mer specifika instruktioner och exempel. Det ska inte vara en parallell minipolicy - en enkel idé är att använda de kanske tre till fem huvudpunkter som du bestämde innan du började skriva.
En enkel introduktion kan exempelvis se ut som följer:
Den här policyn gäller från [datum] och handlar om [kort syfte].
Det viktigaste att förstå i den här policyn är:
- [huvudpunkt]
- [huvudpunkt]
- [huvudpunkt]
Det här förändras: [kort beskrivning, om något faktiskt förändras]
Hela policyn: [länk] Frågor: [kontaktväg]
Det här korta lagret går sedan att använda där det passar, som i mejlet som lanserar policyn, på intranätet, i introduktion för nyanställda eller i material till chefer. Om vissa grupper påverkas särskilt kan kommunikationen runt policyn dessutom anpassas till dem utan att ni börjar skapa olika versioner av själva styrdokumentet.
En bra policy är inte den som innehåller mest
En informationssäkerhetspolicy behöver vara tillräckligt komplett för att faktiskt styra, men den blir inte bättre för varje extra detalj. Den blir bättre när mottagaren kan förstå vilka regler som gäller, omsätta dem i sitt arbete och veta vad som bör göras när verkligheten inte passar perfekt i texten.
Fortsätt här
Sök på sajten →Policymall med kommenterad struktur
En kopierbar policystruktur med kommentarer om vad varje avsnitt ska göra – och vad det inte ska göra.
