Publicerad 12 oktober 2026

Sammanfattning: ”Manipulationssäker” är ett starkt ord som ofta står i produktblad utan att något i lösningen bär det. En logg som administratören själv kan redigera är inte manipulationssäker, oavsett formulering. Det som håller i en granskning är tre saker: att loggen skyddas mot förändring, att ni kan visa hur, och att bevarandetiden räcker till den period granskaren tittar på.

Loggar är det som gör skillnad mellan att tro och att veta vad som hände. Det är också ett av de områden där ordvalet i en upphandling eller en säkerhetsbeskrivning oftast är starkare än tekniken bakom.

Tre nivåer som blandas ihop

Loggen skrivs. Händelsen registreras med tidpunkt, identitet och utfall. Det är utgångsläget, och det är inte alltid uppfyllt – många system loggar inläsningar men inte utläsningar, eller loggar med lokal tid utan tidszon.
Loggen skyddas mot förändring. Behörigheten att radera eller redigera är skild från behörigheten att utföra det som loggas, och posterna skickas vidare från systemet som skapade dem. Det här är den nivå de flesta organisationer realistiskt kan nå.
Loggens integritet har ett starkare tekniskt skydd. Append-only- eller WORM-lagring kan förhindra eller kraftigt begränsa ändringar under bevarandetiden. Kryptografisk integritetskontroll, till exempel en hashkedja mellan posterna eller oberoende tidsstämpling, kan dessutom göra en ändring i efterhand verifierbar. Här kan ni visa hur loggen är skyddad, snarare än att argumentera för att ingen borde ha kunnat ändra den. Vilken teknik ni använder avgör både hur svårt det är att ändra loggen och hur väl en ändring upptäcks i efterhand.

Ordet ”manipulationssäker” går bara att försvara på nivå tre, och även där är ”manipulationsskyddad” eller, med kryptografisk kontroll, ”manipulationsdetekterande” mer exakt: tekniken försvårar eller avslöjar en ändring men gör den sällan helt omöjlig. Skriver ni ”manipulationssäker” utan att ha nivå tre har ni gjort ett påstående som en granskare kan avvisa på fem minuter, och då hamnar även resten av er säkerhetsbeskrivning i fråga.

Frågan som avgör: vem kan ändra loggen?

Det praktiska testet är enkelt och obekvämt. Kan den roll som utförde en åtgärd också radera spåret av den? I många miljöer är svaret ja, eftersom samma domänadministratör eller samma molnadministratörsroll äger både systemet och dess loggar.

Två åtgärder flyttar det mesta: separera behörigheterna så att drift och loggförvaltning inte är samma roll, och vidarebefordra loggen från systemet som skapar den till en plats där den rollen inte har skrivrättighet. Det behöver inte vara en SIEM-plattform för att räknas – en central logginsamling som administratören inte kan städa i är redan en annan situation än en lokal loggfil.

Bevarandetiden är halva frågan

En logg som är perfekt skyddad i 30 dagar hjälper inte i en granskning som tittar på de senaste 12 månaderna. Samtidigt drar dataminimering i andra riktningen: loggar innehåller ofta personuppgifter, och en obegränsad bevarandetid är inte heller rätt svar.

Det som fungerar är att bestämma tiden per loggtyp och kunna motivera den: autentiseringshändelser och administrativa åtgärder längre, applikationsdebug kortare. Skriv ner beslutet. Frågan ”varför sparar ni det här så länge?” kommer från både granskare och dataskyddsombud, och den ska ha samma svar.

Vad standarderna faktiskt kräver

ISO/IEC 27001:2022 behandlar loggning i bilaga A.8.15 och övervakningsaktiviteter i A.8.16: loggar ska produceras, bevaras och skyddas, och de ska granskas. Kontrollen säger inte att loggen måste vara oföränderlig – den säger att den ska skyddas, vilket är exakt den distinktion som gör ”skyddade revisionsloggar” till ett hållbart påstående och ”manipulationssäkra” till ett riskabelt.

Tidsstämplarna behöver också gå att lita på. System som ska jämföras med varandra bör hämta tiden från en gemensam och kontrollerad tidskälla, och tidszon och klockdrift behöver hanteras; ISO/IEC 27001:2022 tar upp det i A.8.17 om klocksynkronisering. Annars går händelserna inte att lägga i rätt ordning när en granskare eller en incidentutredning frågar.

NIS2 och DORA närmar sig samma sak från incidenthållet: rapporteringen kräver att ni kan beskriva vad som hände, när det upptäcktes och vilken påverkan det fick. Loggen är det underlag som gör en sådan beskrivning möjlig att styrka i stället för att rekonstruera ur minnet.

Fyra steg som tar en halvtimme

Utför en åtgärd i ett system som omfattas – lägg till en behörighet, öppna en fil, ändra en inställning.
Hitta åtgärden i loggen. Notera hur lång tid det tog och vad posten innehåller: identitet, tidpunkt, källa och utfall.
Försök radera posten som den roll som utförde åtgärden. Om det går har ni svaret.
Kontrollera hur långt bak loggen faktiskt räcker, inte hur långt policyn säger att den räcker.

Utfallet är antingen ett godkänt test ni kan visa upp, eller en konkret lista på vad som behöver ändras. Bägge är mer värda än formuleringen i produktbladet.

Att verifiera att kontroller fungerar i praktiken, i stället för att de finns beskrivna, är samma arbete som vi går igenom i assurance och kontrolltestning.

Vi arbetar med assurance och internrevision och kan testa loggning och spårbarhet som en avgränsad insats genom vårt erbjudande kontrolltestning. Vill ni veta hur era loggar står sig är ni välkomna att kontakta oss.

Källor: ISO/IEC 27001:2022, bilaga A.8.15 om loggning, A.8.16 om övervakningsaktiviteter och A.8.17 om klocksynkronisering; NIS2-direktivet artikel 21 om riskhanteringsåtgärder och artikel 23 om rapportering; DORA om hantering och rapportering av IKT-relaterade incidenter.

Den här texten är allmän information och utgör inte juridisk rådgivning i ett enskilt ärende.