”Varför då?” Den frågan kommer med stor sannolikhet att dyka upp i huvudet ett antal gånger då en mottagare av en användarpolicy läser igenom den. Men är det ett problem?
Jag påstår att det är det. En policy man som medarbetare och mottagare inte förstår sig på löper stor risk att inte följas. Om det i en policy står skrivet att man inte får ansluta till favoritcaféets Wi-Fi utan närmre förklaring, kommer säkert en och annan fråga sig varför och ansluta i alla fall. Så hur går man tillväga då?
Det finns naturligtvis inga patenterade svar, eftersom alla organisationer är unika. Men här kommer i alla fall några tips som jag tror kan hjälpa till.
Berätta varför
Bästa sättet att undvika frågeställningen ”varför då” är att helt enkelt i förebyggande syfte berätta varför. Var inte rädd för att utveckla den bakomliggande risken och exemplifiera om det är lämpligt. Vad är anledningen att det är en dålig idé att ansluta datorn till ett caféets Wi-Fi? Berätta också gärna i policyns sammanfattning om det övergripande perspektivet – det kanske finns kundkrav och andra externa och interna krav som ligger bakom?
Relevant innehåll
Jag har sett en och annan informationssäkerhetsrelaterad policy som innehåller kontroller som inte nödvändigtvis handlar om säkerhet, utan ibland mer om arbetsmoral och liknande. En policy som säger att man exempelvis inte får använda Spotify utan relevant bakomliggande risk kommer sannolikt inte landa bra. Så se till att alla kontroller i policyn bygger på faktiska och analyserade informationssäkerhetsrisker, det är inte minst viktigt utifrån perspektivet att informationssäkerhetsarbetet bör vara strukturerat och processorienterat. Om det inom vissa grupperingar på grund av arbetets art är olämpligt att lyssna på Spotify ska det hanteras där och inte i informationssäkerhetspolicyn.
Tänk på läsaren
Policyn är inte till för dig som författare utan för mottagaren som ska läsa den. Här kommer organisationen och dess unika förutsättningar in i bilden – du som författare måste rikta dig till mottagarbasen på rätt sätt genom att exempelvis undvika ”corporate bullshit” i policyn. Tekniskt avancerade användare tenderar att oftare undra ”varför”, medan mindre tekniskt avancerade användare oftare frågar sig ”hur”. När jag som mottagare läser en policy kommer den att träffa bättre om jag känner att den är riktad till just mig.
Genomarbetad layout
En policy är som vilken annan trycksak som helst som behöver tilltala grafiskt. Den kan inte bestå av ett antal punktlistor eller ”do’s and don’ts” i tabeller. Varva gärna policyns kontroller (i punkter eller tabell) med förklarande och förtydligande texter där läsaren förstår bakgrunden och därmed stillar behovet att undra varför. Har organisationen tillgång till interna eller externa resurser för grafisk profil bör dessa delta i utformningen så att policyns format passar ihop med övrigt internt material.
Sök acceptans under arbetet
Involvera gärna både interna och externa remissinstanser under arbetet som kan läsa igenom och komma med frågor och synpunkter. Även om man kan (och bör) uppdatera en policy löpande under dess livslängd behöver första versionen kunna landa bra i organisationen.
Hasta inte
Det går inte att hasta fram ett policydokument utan det måste i viss mån få värka fram. Dels utifrån perspektivet att policyn behöver vara komplett från början (bortglömda kontroller är svårt att införliva och implementera i efterhand), dels från perspektivet att formuleringar oftast blir bättre och mer väl avvägda efter några iterationer. Dessutom kanske en och annan kontroll får stryka på foten ifall relevansen är tveksam.
Implementera ordentligt
En policy är inte värd mer än pappret den är utskriven på om den inte implementerats på ett bra sätt. Dels måste den göras tvingande (detta kan vara komplicerat – ta gärna hjälp av arbetsrättsjurist) för de medarbetare som ska omfattas, dels måste medarbetarna ha kunskap om policyn och dess innehåll. Ta höjd för att det kan komma att krävas internutbildning och kanske även en formell sign-off om man man som medarbetare tagit emot policyn.
Under maj 2023 skrev jag om detta även på LinkedIn – läs inlägget här.
