Policyversionering innebär att ni systematiskt spårar, godkänner och bevarar varje ändring i era policydokument, med metadata, sign-off och revisionslogg som minimikrav. Definitionen gäller organisationspolicys som integritetspolicy och informationssäkerhetspolicy, inte teknisk versionshantering av mjukvara. Första åtgärden: inventera era kritiska policyer och utse en ansvarig ägare för var och en redan denna vecka.
Kort sagt:
- ENISA rekommenderar att ledningen granskar säkerhetspolicyn minst årligen och efter en betydande incident; lagändringar och nya verksamhetsgrenar bör också utlösa översyn.
- Varje godkänd version behöver versionsnummer, giltighetsdatum, ansvarig och godkännare med roll och datum samt en ändringsförklaring kopplad till relevant riskbedömning eller incident.
- En namngiven ägare bör ansvara för varje policy, och datumformatet ÅÅÅÅ.MM.DD med en kort ändringskod är enklare att söka än avancerad versionsnumrering.
- Logga varje policyundantag separat med tidsstämpel, motivering och slutdatum, så att ett medvetet avsteg inte förväxlas med bristande efterlevnad.
- Spara äldre versioner enligt fastställd bevarandetid och dokumentera gallringen; radera dem inte vid uppdatering, eftersom ni kan behöva visa vad som gällde då.
Innehållsförteckning
- Varför versionshantering krävs enligt GDPR, NIS2 och ISO
- Vilka metadata och spårfält era policyer måste ha
- Steg för steg: från inventering till drift
- Snabb checklista och mall för policyversionering
- Vanliga fallgropar vid policyversionering och hur vi ser på dem
- Hur Trustview stöder er policyversionering
- Vanliga frågor
- Källor
Varför versionshantering krävs enligt GDPR, NIS2 och ISO
Kravet på strukturerad policyversionering är inte en administrativ nyckel, det följer direkt av gällande regelverk. GDPR ställer krav på lämpliga tekniska och organisatoriska åtgärder samt ansvarsskyldighet, vilket i praktiken betyder att ni måste kunna visa vad som gällde vid en given tidpunkt och varför en ändring gjordes.
ENISA:s implementeringsvägledning går längre och anger att en övergripande säkerhetspolicy ska godkännas av ledningen, omfatta en förteckning över ämnesspecifika policyer och revideras minst årligen eller efter en betydande incident.
Det här är vad revisorer och tillsynsmyndigheter faktiskt letar efter:
- Signaturer och roller som visar vem som godkände en ändring.
- Datum som binder en version till en specifik tidsperiod.
- Kommentarsloggar som förklarar varför ändringen gjordes.
- Koppling mellan policyändring och underliggande riskbedömning.
Enligt ENISA:s vägledning bör ledningen formellt granska policyn minst en gång per år, vilket gör årlig granskning till en rekommenderad baslinje för god efterlevnad. ISO/IEC 27001 bygger på samma logik genom principen om kontinuerlig förbättring: dokument ska kontrolleras, godkännas och hållas aktuella, aldrig frysas i en version som ingen längre äger. Läs mer om hur kontrollerna hänger ihop i vår genomgång av ISO 27002 och informationssäkerhet.
Vilka metadata och spårfält era policyer måste ha
En policy utan metadata är omöjlig att revidera på ett tillförlitligt sätt. Varje version bör bära med sig ett fast antal fält som gör den sökbar, jämförbar och juridiskt försvarbar.
- Versionsnummer: en unik identifierare för varje godkänd version.
- Giltighetsdatum: från vilket datum versionen gäller.
- Ändringsdatum: när innehållet senast redigerades.
- Författare eller ändringsansvarig: vem som utförde ändringen.
- Godkännande: namn, roll och datum för den som sanktionerade versionen.
- Ändringssammanfattning: en kort text om vad som ändrades och varför.
- Kopplade DPIA- eller incident-ID: referens till den riskbedömning eller incident som utlöste ändringen.
Policyundantag behöver en egen logg, separat från huvuddokumentet, där varje undantag tidsstämplas, motiveras och ges ett slutdatum. Utan den loggen blir det svårt att skilja ett medvetet beslut från ett glapp i efterlevnaden.
Metadata är dessutom det som gör rapportering till styrelse och tillsynsmyndighet möjlig utan manuellt letande i mejltrådar. IMY betonar att konsekvensbedömningar ska vara en dokumenterad, löpande process, och samma logik gäller policyändringar som härrör från en DPIA.
Proffstips: Lägg DPIA- och incident-ID som ett obligatoriskt fält redan i mallen, annars glöms kopplingen bort första gången tidspressen är hög.
Steg för steg: från inventering till drift
Att gå från spridda worddokument till en fungerande versionsprocess kräver en tydlig ordning. Nedanstående steg fungerar oavsett om ni hanterar fem eller femtio policyer.
- Inventera och klassificera era policyer. Lista alla gällande dokument och sortera dem efter juridisk vikt, exempelvis integritetspolicy, informationssäkerhetspolicy och leverantörspolicy.
- Utse en ägare per policy. Varje dokument ska ha en namngiven person med mandat att godkänna ändringar, inte en funktionsbrevlåda.
- Bestäm versionsprincip. Ett datumbaserat format som ÅÅÅÅ.MM.DD med en kort ändringskod är enklare att söka och rapportera på än komplicerad semantisk versionering.
- Definiera godkännandeflödet. Ange vem som granskar först, vem som sanktionerar slutligt, och hur lång tid processen får ta.
- Välj teknisk lagring med rätt kontroller. Lösningen måste stödja revisionslogg, åtkomstkontroll och ett tydligt bevarandeschema för äldre versioner.
- Utbilda de som berörs. Jurister, DPO och verksamhetsägare behöver förstå varför fälten finns, inte bara hur de fylls i.
- Genomför en testrevision. Simulera en revisorsgranskning på en policy för att se om metadata, signaturer och loggar håller.
- Definiera KPI:er för efterlevnad. Exempel: andel policyer granskade inom tolv månader, genomsnittlig tid från ändringsbehov till godkännande.
- Fastställ triggers för ny version. En incident, en lagändring eller en ny verksamhetsgren ska alltid utlösa en granskning, inte bara kalendern.
Proffstips: Koppla varje trigger till en ansvarig roll i förväg, så att en incident inte behöver vänta på att någon frågar vem som ska agera.
Processen hänger tydligt ihop med era NIS2-skyldigheter när policyn rör nätverks- och informationssäkerhet. Vår genomgång av NIS2-efterlevnad går igenom hur krav på ledningsgodkännande och riskhantering vävs in i samma arbetsflöde.
Snabb checklista och mall för policyversionering
En kopierbar struktur sparar tid första gången ni sätter upp processen och varje gång en policy uppdateras därefter.
Checklista per version:
- Versionsnummer och giltighetsdatum ifyllda.
- Ändringsansvarig och godkännare namngivna med roll och datum.
- Ändringssammanfattning skriven i klartext, inte bara “mindre justering”.
- Koppling till DPIA- eller incident-ID angiven om relevant.
- Föregående version arkiverad med åtkomstbegränsning, inte raderad.
Malltext för ändringslogg: “Version [nummer], godkänd av [namn, roll] den [datum]. Ändring: [kort beskrivning]. Utlöst av: [incident/DPIA/lagändring/rutinöversyn].”
Som bevarandeprincip gäller att äldre versioner ska sparas enligt en fastställd retentionstid snarare än kastas direkt, och disposition ska vara dokumenterad och spårbar. Den som vill fördjupa kopplingen till konsekvensbedömningar kan se vår guide om bedömning av konsekvenser för konkreta exempel på fält som går att återanvända i policymallen.
Vanliga fallgropar vid policyversionering och hur vi ser på dem
De vanligaste problemen vi stöter på handlar sällan om tekniken, utan om ägarskap. Otydligt ägarskap gör att ändringar blir ingens ansvar, sporadiska granskningar gör att en policy kan ligga oreviderad i flera år utan att någon märker det, och separata system utan gemensamt arbetsflöde skapar versioner som aldrig synkroniseras mellan juridik och IT.
Struktur och automation minskar normalt arbetsbördan för jurister och dataskyddsombud genom att flytta ansvaret från minnet till systemet: triggers, påminnelser och färdiga fält gör att rätt person agerar vid rätt tillfälle, inte bara när en revisor frågar.
— Jesper
Hur Trustview stöder er policyversionering
Vi har byggt Trustview för att samla juridiskt, operativt och styrande arbete på ett ställe, så att ni slipper jaga versioner i separata dokument och mejltrådar. Plattformen gör det enklare att hantera registerförteckningar, genomföra risk- och konsekvensbedömningar, logga incidenter, bedöma leverantörer, fördela ansvar och följa upp åtgärder, allt kopplat till samma underliggande struktur som era policyer bygger på.
Det betyder att en policyändring kan knytas direkt till den DPIA eller incident som utlöste den, med automatisk spårning av vem som godkänt vad och när.
- Se prisinformation för Trustview från 2 500 kr per månad.
- Boka juridisk rådgivning om ni behöver hjälp att formulera sign-off-processen.
- Läs om hur ett riskbaserat angreppssätt hjälper er prioritera vilka policyer som granskas först.
Nästa steg är att se plattformen i praktiken och avgöra om den passar er nuvarande process.
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
Vanliga frågor
Vad är skillnaden mellan policyversionering och policyhistorik?
Policyversionering är själva processen för att skapa, godkänna och dokumentera nya versioner av ett policydokument. Policyhistorik är resultatet, det samlade arkivet av tidigare versioner med tillhörande metadata som ni kan gå tillbaka till vid en revision.
Hur ofta måste vi granska våra policyer enligt regelverken?
ENISA:s vägledning anger att en övergripande säkerhetspolicy bör revideras minst en gång per år eller efter en betydande incident. Samma princip gäller normalt för integritetspolicyer kopplade till GDPR, där ändringar i verksamheten eller lagstiftningen också bör trigga en översyn.
Vilka metadata är absolut nödvändiga i en policyversion?
Minimikravet är versionsnummer, giltighetsdatum, ändringsdatum, ansvarig författare och ett formellt godkännande med namn, roll och datum. Lägg även till en kort ändringssammanfattning och, där relevant, en koppling till DPIA- eller incident-ID för att göra ändringen juridiskt spårbar.
Hur länge ska vi bevara äldre policyversioner?
Äldre versioner ska sparas enligt en fastställd retentionstid snarare än raderas direkt vid uppdatering, med dokumenterad disposition när de slutligen gallras. Principen är att kunna visa vad som gällde vid en specifik tidpunkt, även flera år senare om en tvist eller tillsyn kräver det.
Kan Trustview hjälpa oss sätta upp en versionsprocess för policyer?
Ja, Trustview samlar juridiskt och operativt arbete i en plattform där policyändringar kan kopplas till riskbedömningar, incidenter och ansvariga roller. Priser finns listade från 2 500 kr per månad, och juridisk rådgivning för att bygga själva godkännandeflödet går att beställa separat.
Källor
- ENISA – Implementation guidance on security measures (2024)
- IMY – Hur ska en konsekvensbedömning genomföras?
- EU GDPR (förordning (EU) 2016/679)
