I många små och medelstora företag görs säkerhetspolicyn först när en kund efterfrågar den i en offertprocess eller när ett ISO 27001-projekt redan är igång. Resultatet blir då lätt ett övergripande papper som ser bra ut vid en revision men som inte styr vardagens beslut, ansvar eller verksamhet.
I denna artikel går vi igenom vad ISO 27001 kräver av en säkerhetspolicy, vad som bör skrivas in och hur ni praktiskt bygger ett fungerande dokument. Ni får en tydlig steg-för-steg-modell, exempelstruktur, ansvar och mätetal för att policyn ska leva även efter publiceringen.
Förutsättningar
- En utsedd ägare för policyn, till exempel VD, säkerhetsansvarig eller kvalitets-/IT-chef
- Definierat tillämpningsområde, alltså vilken verksamhet, tjänster, platser och system som ISO 27001-styrsystemet gäller för
- Grundläggande förståelse för företagets 3–5 viktigaste säkerhetsrisker
- Beslut om vem som godkänner policyn och hur ofta den ses över, till exempel var 12:e månad
Vad betyder säkerhetspolicy i ISO 27001?
I ISO 27001 är policyn en ledningsfastställd riktlinje för hur organisationen styr sitt informationssäkerhetsledningssystem. I praktiken berättar den vad företaget skyddar, varför det skyddas och med vilka principer skyddet utförs. Det är alltså inte bara en säkerhetsinstruktion för medarbetare, utan ett vägledande dokument för hela systemets inriktning.
En bra policy svarar åtminstone på följande frågor:
- Vilken information, tjänster och processer skyddar företaget?
- Vilka är säkerhetsmålen under de kommande 12 månaderna?
- Vem ansvarar för beslut, uppföljning och hantering av avvikelser?
- Hur bedöms risker och hur väljs kontroller?
- Hur följs efterlevnaden av policyn i praktiken?
I små och medelstora företag är policyn ofta som mest fungerande när den är 1–3 sidor lång. Blir dokumentet 8–10 sidor riskerar det lätt att förväxla själva policyn med rutiner och detaljerade instruktioner.
Observera
ISO 27001 kräver inte att säkerhetspolicyn är ett långt eller juridiskt dokument. Det viktiga är att ledningen godkänner den, att innehållet passar organisationens syfte och att policyn även underhålls.
Vad ska finnas med i policyn som minimum?
ISO 27001 ger ingen färdig mall, men i praktiken bör policyn vara så tydlig att revisor, medarbetare och kund förstår den på samma sätt. Är innehållet för allmänt styr policyn inget. Skriver ni däremot in för många detaljer blir den snabbt inaktuell.
En fungerande minimistruktur ser ofta ut så här:
| Delområde | Vad som skrivs in | Praktiskt exempel |
|---|---|---|
| Syfte | Varför policyn finns | Företaget skyddar kund-, personal- och affärsinformation för att hantera risker och säkerställa tjänsternas kontinuitet |
| Tillämpningsområde | Vilka funktioner, enheter och system policyn gäller för | Policyn omfattar SaaS-tjänsten, supporttjänsten, interna IT-system och distansarbete |
| Säkerhetsmål | 3–5 mätbara mål | Kritiska åtkomsträttigheter granskas kvartalsvis |
| Principer | Kärnregler för säkerhetsstyrning | Åtkomsträttigheter ges enligt principen om minsta möjliga rätt |
| Ansvarsfördelning | Vem äger, godkänner och följer upp | VD godkänner, IT-chef underhåller, närmaste chef övervakar genomförandet |
| Uppföljning och förbättring | Hur policyn ses över | Policyn ses över var 12:e månad eller vid väsentliga förändringar |
När ni formulerar mål, undvik vaga uttryck som "vi förbättrar säkerheten". Det är bättre att definiera mål, mätetal och tidsgräns:
- Flera faktors autentisering används på 100 % av underhållskonton inom 3 månader.
- Åtkomsträttigheter för avgångna medarbetare tas bort inom 24 timmar efter anställningens slut.
- Informationssäkerhetsavvikelser behandlas preliminärt inom 1 arbetsdag från upptäckt.
Policyn är inte samma sak som instruktioner
Detta är en av de vanligaste förväxlingarna. Säkerhetspolicyn anger riktning och principer. Instruktioner och rutiner berättar däremot i detalj hur något görs i praktiken.
Tänk så här:
- Policyn säger att åtkomsträttigheter ska hanteras kontrollerat.
- Rutinen beskriver vem som godkänner åtkomstansökningar.
- Arbetsinstruktionen visar vilka knappar som ska klickas i systemet.
Om ni skriver in till exempel en detaljerad backupschema eller exakt ticketprocess i policyn blir dokumentet omedelbart inaktuellt när verktyget byts ut. Därför är det klokt att hålla policyn stabil och lägga de rörliga detaljerna i separata dokument.
Varning
Ett vanligt misstag är att kopiera en policymall rakt av utan att ta hänsyn till den egna verksamheten, riskerna och ansvarsfördelningen. Revisorn märker snabbt detta, men ännu viktigare är att personalen inte känner dokumentet som sitt eget.
Hur knyts policyn till företagets risker och mål?
Kärnan i ISO 27001 är riskbaserat tänkande. Det betyder att ni inte bygger policyn för att standarden säger så, utan för att ert företag har verkliga risker: kunddata kan läcka, tjänsten kan avbrytas eller åtkomsträttigheter kan finnas kvar för länge.
Börja med att lista 3–5 centrala risker. Säkerställ sedan att principer och mål i policyn kopplas just till dessa. Exempel:
| Central risk | Policyns princip | Mätetal |
|---|---|---|
| Avgångna medarbetares konton kvarstår | Åtkomsträttigheter tas bort kontrollerat vid anställningens slut | Borttagning utförd inom 24 h |
| Kunddata hanteras med för vida rättigheter | Principen om minsta möjliga rätt används | Rättighetsgranskning 4 gånger per år |
| Tjänststörning stoppar kundarbete | Kontinuitetskrav definieras för kritiska tjänster | Återställningstest utfört 2 gånger per år |
| Phishing leder till kontoläckage | Personal utbildas och autentisering stärks | Utbildningsgrad 95 % per år |
När policyn kopplas till riskerna blir den ett ledningsverktyg och inte bara ett certifieringsprojektets bilaga. Samtidigt underlättas även resursbeslut: ni vet vad ni bör prioritera först.
Vem godkänner policyn och hur underhålls den?
ISO 27001 betonar ledningens roll. I praktiken betyder det att policyn inte bara bör publiceras som ett internt IT-dokument. Ledningen ska godkänna den öppet och visa att informationssäkerheten kopplas till affärsmålen.
En tydlig ansvarsfördelning kan se ut så här:
| Roll | Ansvar |
|---|---|
| VD | Godkänner policyn och säkrar resurser |
| IT-chef / säkerhetsansvarig | Förbereder, uppdaterar och följer upp genomförandet |
| Chefer | Säkerställer att team följer policyn |
| Medarbetare | Följer instruktioner och rapporterar avvikelser |
Underhållet följer en enkel rytm:
- Se över policyn minst en gång om året.
- Uppdatera alltid efter väsentliga förändringar, såsom företagsförvärv, ny SaaS-tjänst eller outsourcing.
- Dokumentera godkännandedatum, versionsnummer och ägare.
- Kommunicera förändringar till personalen inom 7 dagar från godkännandet.
Tips
Lägg till en enkel versionshanteringsrad längst ner i policyn: ägare, godkännare, godkännandedatum och nästa översynsdatum. Det kan ni börja använda direkt utan separat projekt.
Definiera policyns syfte och tillämpningsområde
Beskriv först i ett stycke vilken verksamhet, vilka tjänster, data och platser policyn gäller för. Håll avgränsningen konkret: till exempel SaaS-tjänst, kundsupport, intern IT och distansarbetsmiljö. Är tillämpningsområdet oklart blir även revisionen och ansvarsområdena otydliga.
Välj 3–5 huvudmål för informationssäkerheten
Formulera målen mätbara för nästa 12-månadersperiod. Använd mål–mätetal–tidsgräns-modellen, som "åtkomsträttigheternas borttagning inom 24 timmar" eller "MFA-täckning på underhållskonton 100 %". Då styr policyn handlingar och förblir konkret.
Ange kärnprinciper för informationssäkerhetsstyrningen
Välj 5–7 principer som är stabila även vid verktygsbyte. Bra exempel är principen om minsta möjliga rätt, riskbaserat beslutsfattande, rapportering av avvikelser samt kontinuerlig förbättring. Undvik alltför tekniska detaljer i detta skede.
Utnämn ansvar och få ledningens godkännande
Ange tydligt vem som äger policyn, vem som uppdaterar den och vem som godkänner. Säkerställ att ledningen formellt godkänner dokumentet, till exempel i ledningsgruppsmöte eller via digital signering. Utan detta blir policyn lätt bara ett IT-dokuments.
Publicera, kommunicera och följ upp genomförandet
Spara policyn där personalen hittar den på under 2 minuter, till exempel på intranätet eller i ledningssystemets dokumentbank. Informera om ändringar, länka policyn till introduktion och följ upp minst 3 mätetal månads- eller kvartalsvis. Då blir dokumentet praktisk styrning.
Exempelstruktur för en fungerande säkerhetspolicy
Om ni funderar på var ni ska börja kan ni använda denna struktur. Den räcker för de flesta små och medelstora företag och är enkel att hålla aktuell.
- Policyns syfte
- Tillämpningsområde
- Säkerhetsmål
- Informationssäkerhetsprinciper
- Roller och ansvar
- Åtagande att följa lagar, avtal och krav
- Uppföljning, översyn och kontinuerlig förbättring
- Godkännande och versionshantering
Testa strukturen med tre frågor:
- Förstår en nyanställd policyns innehåll på 10 minuter?
- Kan ledningen hitta sina ansvar utan extra förklaringar?
- Kan en revisor koppla policyns mål till praktiska mätetal?
Om svaret är nej behöver policyn kortas ner eller bli mer konkret.
Vanligaste misstagen i små och medelstora företag
De flesta problemen beror inte på att policyn saknas utan på att den inte knyts till vardagen. Känner ni igen någon av dessa?
- Policyn är direkt kopierad från mall och saknar företagets egna risker.
- Målen är inte mätbara eller saknar tidsgräns.
- Ansvar anges allmänt som "organisationen ansvarar".
- Dokumentet sparas på en plats där personalen inte hittar det.
- Policyn ses inte över efter förändringar.
Åtgärden lyckas oftast snabbt. Avsätt 60–90 minuter för workshop, gå igenom risker, ansvar och mätetal, och uppdatera policyn i en vända. Ofta lyfter detta dokumentet till en helt annan nivå.
Hur underlättar Tietoturvapankki policylösningen?
När ni jobbar med ISO 27001 mitt i den hektiska vardagen är den största utmaningen ofta inte att skriva utan att hålla koll på helheten. Policyn ska kopplas till risker, mål, kontrollurval, dokument och översyner. Om dessa finns i olika filer och hos olika ägare går underhållet snabbt långsamt.
Tietoturvapankki kombinerar app och expertstöd så att policyn inte blir ett isolerat dokument. När ledningssystemets delar finns samlade ser ni lättare hur policyn länkas till riskbedömningar, ansvar och kontinuerlig förbättring. Detta är särskilt värdefullt för små och medelstora företag utan separat säkerhetsteam.
Tänk också på att liknande arbetssätt finns från andra standarder. Har ni erfarenhet av till exempel ISO 9001-ledning eller Kvalitetsbanken-lösningar fungerar samma grundlogik även för informationssäkerhet: definiera mål, ansvar, uppföljning och förbättring tydligt. Arbetsmetoder med rötter i Softapankki Oy och QMClouds Oy har gjort denna ansats välbekant för många företag.
Sammanfattning
- Säkerhetspolicyn är en ledningsfastställd riktlinje som styr hela ISO 27001-ledningssystemet.
- En fungerande policy är vanligtvis 1–3 sidor och innehåller syfte, tillämpningsområde, mål, principer, ansvar och översynsprocess.
- Formulera alltid mål som mätbara: till exempel borttag av rättigheter inom 24 timmar eller rättsgranskning 4 gånger per år.
- Förväxla inte policy med instruktioner: policyn visar riktning, rutiner och arbetsinstruktioner beskriver detaljer.
- När policyn kopplas till företagets egna risker och följs regelbundet blir den ett verkligt ledningsverktyg.
Behöver ni hjälp med informationssäkerhet?
Våra experter hjälper er vidare.