En informationssäkerhetspolicy ska tala om vad organisationen vill skydda, vem som fattar beslut och vilka regler som ska följas. En användbar policy kopplar varje regel till en ansvarig funktion, en praktisk rutin och en kontroll av att rutinen fungerar. Formuleringar som ”vi har hög säkerhet” hjälper varken medarbetaren som behöver dela en fil eller ledningen som ska prioritera en brist.
Här får du en struktur för att skriva policyn och ett ifyllt exempel som visar hur den kan omsättas i vardagen. Exemplen är konstruerade arbetsmodeller. De ska anpassas till verksamhetens behandlingar, risker och tillämpliga regler.
Vad är en informationssäkerhetspolicy?
Policyn är ledningens övergripande styrning av informationssäkerheten. Den beskriver mål, omfattning, ansvar och principer för bland annat behörighet, incidenthantering och kontinuitet. Detaljer som klickordningen för att stänga ett konto hör vanligen hemma i en underordnad rutin. Policyn pekar ut vilken rutin som gäller och vem som förvaltar den.
Informationssäkerhet omfattar mer än personuppgifter: även avtal, affärshemligheter och andra verksamhetsuppgifter kan behöva skydd. Dataskyddet fokuserar på människor vars uppgifter behandlas. IMY:s vägledning om informationssäkerhet beskriver säkerhetsarbetet som en del av skyddet för personuppgifter. Policyn bör därför kopplas till dataskyddsarbetet utan att behandla alla säkerhetsfrågor som samma juridiska uppgift.
Börja med omfattning och skyddsmål
Ange vilka bolag, enheter, platser och informationsmiljöer som omfattas. Ta med molntjänster, externa driftpartners, distansarbete och pappersinformation där dessa ingår i verksamheten. En policy som bara gäller ”IT-avdelningens system” kan lämna inköpta HR-tjänster och lokala delningsmappar utanför.
Skriv skyddsmålen utifrån konkreta konsekvenser. Kunduppgifter ska exempelvis vara tillgängliga för behörig kundservice, korrekta nog att stödja rätt beslut och skyddade från obehörig läsning. Spårbarhet behövs när organisationen ska kunna förstå vem som ändrat eller lämnat ut information. Målen kan stå i konflikt; obegränsad åtkomst för att förenkla arbetet är inte en hållbar lösning.
Gör först en kartläggning av IT-system och dataflöden. Koppla den till registerförteckningen enligt artikel 30, men slå inte ihop dokumenten till en enda otydlig lista. Systemkartan visar teknik och beroenden. Registerförteckningen beskriver behandlingar och deras ändamål.
Bedöm riskerna innan reglerna formuleras
Utgå från vad som kan hända med informationen. En felaktig behörighet kan exponera personalärenden. En avstängd integration kan göra kunddata inaktuella. En otillgänglig säkerhetskopia kan hindra återställning. Beskriv både orsaken och följden, så att den föreslagna åtgärden kan bedömas mot rätt problem.
Artikel 32 i dataskyddsförordningen kräver lämpliga tekniska och organisatoriska åtgärder med hänsyn till bland annat risk, behandlingens sammanhang och tillgänglig teknik. Den föreskriver inte att alla organisationer ska använda samma namngivna policy, produkt eller tekniska värde. Särskilda verksamheter kan samtidigt omfattas av mer preciserade regler som måste identifieras separat.
Dokumentera befintliga skydd och verkliga brister. Om flerfaktorsautentisering redan gäller för vanliga användare men inte administratörer, ska policyn inte beskriva hela miljön som färdig. Skilj på det beslutade kravet och den del som återstår att genomföra. Det ger ledningen en möjlighet att prioritera rätt arbete.
Fördela beslut, genomförande och granskning
Utse en ägare för policyn och ansvariga för de viktigaste rutinerna. Ledningen behöver besluta om inriktning och resurser. Systemägare behöver bedöma vilka roller som ska få tillgång. IT-funktionen behöver kunna genomföra och verifiera ändringarna. HR måste till exempel signalera anställningar, rollbyten och avslut i tid.
Dataskyddsombudet ger råd och övervakar efterlevnaden inom sin roll. Ombudet ska inte göras till beslutsfattare för alla operativa säkerhetsval och därefter förväntas oberoende granska samma beslut. Se dataskyddsombudets uppgifter och ställning när ansvarsfördelningen fastställs.
En enkel ansvarstabell bör visa vem som beställer, godkänner, utför och följer upp. Samma person kan ha flera uppgifter i en liten organisation, men det behöver finnas en medveten kontroll av särskilt känsliga beslut. En administratör ska exempelvis inte själv kunna ge sig obegränsad åtkomst utan efterföljande insyn.
Mall: policyns centrala delar
| Del | Vad den ska bestämma | Exempel på underlag |
|---|---|---|
| Omfattning och mål | Vilken information och verksamhet som skyddas | Systemkarta och informationsklassning |
| Ansvar och beslut | Vem som äger regler, risker och åtgärder | Ansvarstabell och mandat |
| Åtkomst | Hur behov prövas och rättigheter ändras | Behörighetsrutin och granskningsresultat |
| Säker drift | Hur system hålls uppdaterade och skyddade | Härdningsprofil och ändringsrutin |
| Spårbarhet | Vilka säkerhetshändelser som följs upp | Loggkatalog och larmansvar |
| Incidenter | Hur avvikelser rapporteras och bedöms | Kontaktvägar och incidentrutin |
| Kontinuitet | Hur prioriterade funktioner fortsätter eller återställs | Reservrutiner och övningsresultat |
| Uppföljning | Vad som granskas och när beslut omprövas | Kontrollplan och versionshistorik |
Tabellen är en arbetsstruktur, inte en uttömmande svensk lagstadgad innehållsförteckning. Lägg till verksamhetsspecifika krav där de behövs. Undvik samtidigt att fylla huvudpolicyn med installationsinstruktioner som blir inaktuella vid nästa systemversion.
Ifyllt exempel: åtkomst till kundsystemet
I ett konstruerat serviceföretag beslutar ledningen följande regel: ”Tillgång till kundsystemet ska vara personlig och begränsad till arbetsuppgiften. Systemägaren godkänner rollen innan IT tilldelar den. Administrativ åtkomst ska användas separat från den vanliga användarrollen.”
Den kopplade rutinen anger att närmaste chef skickar en beställning med arbetsuppgift och önskad roll. Systemägaren jämför behovet med rollbeskrivningen. IT registrerar vem som godkänt och genomför tilldelningen. Vid byte från kundservice till ekonomi tas kundservicerollen bort om den inte längre behövs; en ny roll får inte bara läggas ovanpå den gamla.
Kontrollen består av ett urval av verkliga rollbyten. Granskaren jämför beställning, godkännande och aktuell åtkomst. I exemplet hittas en tidigare kundservicemedarbetare med kvarvarande exportbehörighet. Rättigheten tas bort och orsaken spåras till att HR:s rollbytesmeddelande inte nådde systemägaren. Åtgärden blir därför både en korrigerad behörighet och en ändrad meddelanderutin.
Autentiseringen beskrivs mer detaljerat i lösenordspolicyn och MFA-rutinen. Händelser som behöver följas upp kopplas till säkerhetsloggningen. På så sätt går policyn att följa utan att samma tekniska instruktion behöver upprepas i flera dokument.
Skriv en hanterbar rutin för undantag
Undantag behöver ett faktiskt skäl, en tydlig avgränsning och en tidpunkt för omprövning. ”Systemet är gammalt” förklarar en begränsning men visar inte varför risken är acceptabel. Dokumentera berörda uppgifter, vad som hindrar huvudregeln, tillfälliga skydd och vem som beslutar om fortsatt drift.
I serviceexemplet kan en äldre integration tillfälligt sakna den autentiseringsmetod som policyn kräver. Beslutet kan då begränsa integrationskontots åtkomst, tillåta anslutning bara från en bestämd miljö och ange ett datum för byte av lösning. Det är en lokal riskhantering som måste bedömas i sitt sammanhang. Ett internt undantag kan inte sätta ett bindande lagkrav ur spel.
Förvara undantagen så att policyägaren kan se vilka som fortfarande är öppna. En gammal e-posttråd som ingen bevakar blir lätt en permanent dispens. När förutsättningen ändras ska undantaget stängas eller prövas igen.
Knyt incidenter och kontinuitet till vardagsreglerna
Medarbetarna behöver veta hur de rapporterar felaktig delning, misstänkt kontoanvändning och förlorad utrustning. Kontakten ska fungera även när ordinarie e-post är otillgänglig. Beskriv vem som gör den första bedömningen och hur frånvaro hanteras.
Använd rutinen vid personuppgiftsincident för dataskyddsbedömningen. En säkerhetshändelse och en anmälningspliktig personuppgiftsincident är inte samma sak. Policyn ska se till att rätt bedömning sker snabbt, utan att varje tekniskt larm automatiskt beskrivs som en incident som ska anmälas.
Koppla också till kontinuitetsplanen. En reservrutin får inte skapa obegränsade privata kopior av kundregistret. I exemplet prövar företaget hur ett begränsat orderunderlag kan användas under ett avbrott och återföras säkert när systemen fungerar igen.
Besluta, inför och följ upp policyn
Lämna inte bara ett färdigt dokument till ledningen. Visa vilka regler som redan fungerar, vilka brister som återstår och vilket arbete som krävs för att stänga dem. Efter beslutet ska berörda medarbetare få veta vad som ändras i deras egna arbetsuppgifter. En kvittens på att dokumentet mottagits visar inte att rutinen är förstådd.
Låt uppföljningen omfatta några konkreta frågor: stängs åtkomst vid avslut, fungerar larmmottagningen, går säkerhetskopian att återställa och är undantagen fortfarande motiverade? Bevara resultaten tillsammans med beslut om åtgärder. Ansvarsskyldighetens bevisregister kan knyta samman dessa kontroller.
Bestäm både en planerad översyn och händelser som utlöser tidigare granskning, exempelvis en ny leverantör, ett allvarligt tillbud eller en organisationsförändring. Policyn är då ett styrdokument som kan ändras när verkligheten ändras, med en spårbar förklaring till vad som beslutats och varför.