Åtkomstloggning måste vara riskbaserad, dokumenterad och revisionsbar. Det innebär i praktiken att inloggningar, behörighetsändringar, administratörsåtgärder och dataexporter alltid ska loggas, eftersom detta räknas som en del av de tekniska och organisatoriska åtgärderna enligt artikel 24 och 32. Nästa steg är konkret: skriv eller uppdatera er loggpolicy, gör en källinventering av alla system som hanterar personuppgifter, och börja samla in loggar centralt innan ni bygger vidare på detektering och larm.
Kort sagt:
- Loggpolicy och registerförteckning måste vara riskbaserade, dokumenterade och kopplade till organisationens DPIA för att säkerställa efterlevnad.
- All inloggning, behörighetsändringar och dataexporter ska loggas och granskas för att kunna bevisa laglig behandling och upptäcka obehörig åtkomst.
- Loggar bör samlas centralt, skyddas mot ändring och synkroniseras via NTP för att vara tillförlitliga vid incidentutredningar.
- Lagring av loggar ska baseras på en riskbedömning, med tydliga policys för både lagringstid och skydd, inklusive kryptering och strikta åtkomstkontroller.
- Använd ett system som samordnar loggpolicy, register och uppföljning för att underlätta dokumentation, ansvar och efterlevnad.
Innehållsförteckning
- Vad är åtkomstloggning enligt GDPR och vilka händelser ska loggas?
- Vilken juridisk grund kräver loggning enligt GDPR och NIS2?
- Hur bygger man en teknisk arkitektur för revisionsbara loggar?
- Hur länge ska åtkomstloggar sparas enligt GDPR?
- Vad ska ingå i biträdesavtalet när loggning sker i molnet?
- Hur kommer man igång med åtkomstloggning på 90 dagar?
- Trustview-perspektivet på loggning som administrativ börda
- Så stöttar Trustview er dokumentation av åtkomstloggning
- Källor
Vad är åtkomstloggning enligt GDPR och vilka händelser ska loggas?
Åtkomstloggning under GDPR handlar om att registrera vem som gjort vad, när och mot vilken uppgift. Syftet är dubbelt: ni ska kunna bevisa att behandlingen skett lagligt, och ni ska kunna upptäcka och utreda obehörig åtkomst. Ett journalsystem inom vården eller ett dokumenthanteringssystem med känsliga personuppgifter kräver en mer detaljerad logg än ett internt intranät, eftersom risken för skada vid felaktig åtkomst är högre.
Följande händelser bör alltid loggas:
- Lyckade och misslyckade inloggningsförsök, inklusive användning av multifaktorautentisering (MFA)
- Sessionsstart och sessionsslut, särskilt vid fjärråtkomst
- Ändringar av behörigheter, roller och åtkomsträttigheter
- Administratörskommandon, till exempel ändringar i systemkonfiguration
- Export av data, nedladdningar och utskrifter av personuppgifter
- Ovanliga läsningar, som när en anställd öppnar en journal utan koppling till sitt arbete
Varje händelsetyp fyller en funktion. Behörighetsändringar visar om någon fått åtkomst de inte borde ha. Dataexporter är ofta den mest kritiska punkten vid en incidentutredning, eftersom de avgör om en läcka faktiskt inneburit att uppgifter lämnat organisationen.
Vilken juridisk grund kräver loggning enligt GDPR och NIS2?
GDPR ställer inte upp en checklista för loggning rad för rad, men artikel 5.2 kräver ansvarsskyldighet, artikel 24 kräver lämpliga tekniska och organisatoriska åtgärder, och artikel 32 kräver förmåga att säkerställa konfidentialitet, integritet och tillgänglighet över tid. En praktisk tolkning av dessa krav visar att loggning är en central komponent i att kunna dokumentera tekniska och organisatoriska åtgärder på ett sätt en tillsynsmyndighet kan granska.
NIS2 går ett steg längre för organisationer inom kritisk infrastruktur och viktiga samhällsfunktioner. Direktivet specificerar operativa krav på övervakning och dokumentation, snarare än GDPR:s mer ändamålsorienterade skrivning. Skillnaden märks tydligast i detaljnivån: NIS2 pekar ut loggkategorier medan GDPR lämnar utformningen öppen så länge risken är hanterad. Praktiskt betyder det att ni behöver tre artefakter i era styrdokument: en loggpolicy, en anteckning i registerförteckningen (RoPA) som pekar på var loggning sker, och en referens i er DPIA där loggning motiveras som riskreducerande åtgärd.
Hur bygger man en teknisk arkitektur för revisionsbara loggar?
En logg som inte går att lita på är värdelös vid en incidentutredning. Arkitekturen måste därför byggas för att motstå både tekniska fel och avsiktlig manipulation.
Tre arkitektoniska val avgör om loggarna faktiskt håller vid en granskning:
- Centraliserad insamling. Samla loggar från alla källsystem i ett gemensamt lager, normalisera formaten, och skicka dem vidare till ett SIEM-system eller en logghanteringsplattform. Central analys och tuning är det som gör att avvikelser faktiskt upptäcks, inte bara sparas.
- Immutability, alltså skydd mot ändring. Loggarna ska lagras append only, det vill säga att inget kan raderas eller redigeras i efterhand utan att det syns.
- Tidssynkronisering via NTP. Utan en gemensam tidskälla blir det omöjligt att korrelera händelser mellan system vid en utredning.
Utöver detta krävs TLS för överföring mellan system, strikt åtkomstkontroll till loggmiljön, och, kanske viktigast: loggning av vem som får åtkomst till loggarna själva. Ett vanligt misslyckande är att glömma just det sista steget, vilket gör att en insider kan radera spår efter sig utan att det upptäcks.
Proffstips: Inför tvåpersonersprincip för export av loggdata. Ingen enskild person ska kunna exportera eller radera loggar utan att en annan behörig person godkänner eller loggas som medgranskare.
I drift handlar det sedan om att successivt finjustera larmregler så att ni fångar verkliga avvikelser utan att dränkas i falsklarm. Artikel 32:s krav på kontinuitet förutsätter att analysen faktiskt sker löpande, inte bara att data samlas in och glöms bort.
Hur länge ska åtkomstloggar sparas enligt GDPR?
Det finns inget fast lagkrav på exakt antal månader. Både GDPR och NIS2 kräver istället en riskbaserad motivering som ni kan visa upp vid en granskning. En vanlig praxis är att hålla loggar tillgängliga varmt under en period för snabb sökning, och därefter arkivera dem kallt under en längre tid som referens vid utredningar som upptäcks sent.
Proffstips: Bygg retentionpolicyn som en enkel matris: hotmodell, undersökningsbehov och kostnad mot åtkomlighet. Den bedömningen är precis det en riskbaserad ansats till retention innebär, och den gör det lättare att motivera valet för en revisor.
Retentiontiden måste alltid vägas mot reglerna för hur länge personuppgifter får sparas generellt, eftersom loggar i sig innehåller personuppgifter.
Skyddet av loggarna är lika viktigt som lagringstiden:
- Kryptering av loggdata både vid lagring och överföring
- Strikta åtkomstkontroller kopplade till roll, inte till individ
- Immutable lagring som förhindrar manipulation i efterhand
- Egen loggning av vem som läser eller exporterar loggdata
Vad ska ingå i biträdesavtalet när loggning sker i molnet?
När loggdata hanteras av en molnleverantör flyttas inte ansvaret, bara vissa av de tekniska uppgifterna. Ni som personuppgiftsansvarig behöver konkreta garantier i avtalet, inte löften i marknadsföringen.
Kräv följande i biträdesavtalet (DPA) och tillhörande säkerhetsbilaga:
- Tydlig angivelse av var loggdata fysiskt lagras
- Möjlighet att exportera loggar i ett användbart format vid en incident
- Skriftlig bekräftelse på immutability, alltså att leverantören inte kan redigera loggarna i efterhand
- Definierad SLA för hur snabbt leverantören lämnar ut loggdata vid en incidentutredning
- Stöd för forensiska exporter som håller som bevis
Testa avtalet i praktiken innan ni litar på det. Begär ett stickprov på loggexport, kontrollera att tidsstämplarna stämmer mot er egen NTP-källa, och verifiera att formatet faktiskt går att importera i ert eget SIEM-system. Leverantören ansvarar för den tekniska infrastrukturen och att exponera loggfunktionerna, men konfiguration, verifiering och den slutgiltiga bedömningen av om skyddet räcker ligger alltid kvar hos er som personuppgiftsansvarig.
Hur kommer man igång med åtkomstloggning på 90 dagar?
En teoretisk policy hjälper ingen om den inte omsätts i konkreta steg med tydliga ägare. Dela upp arbetet i tre faser om 30 dagar vardera.
- Dag 0–30: Inventering och prioritering. Kartlägg alla system som behandlar personuppgifter, identifiera vilka som redan loggar tillräckligt och vilka som saknar spårbarhet helt. Prioritera journalsystem, dokumenthanteringssystem och system med adminrättigheter högst.
- Dag 31–60: Central insamling och konfiguration. Koppla prioriterade källsystem till en central logghanteringslösning, definiera normaliseringsregler, och sätt upp grundläggande larm för de mest kritiska händelserna som misslyckade inloggningsförsök i mängd och obehöriga behörighetsändringar.
- Dag 61–90: Dokumentation och uppföljning. Färdigställ loggpolicyn, uppdatera registerförteckningen med referenser till var loggning sker, koppla ihop dokumentationen med er DPIA, och genomför en första accessrecension.
Proffstips: Rapportera tre mätetal till ledningen eller dataskyddsombudet varje kvartal: hur stor andel av systemen som täcks av central loggning, antal kritiska larm som genererats, och hur många accessrecensioner som faktiskt genomförts. Dessa siffror gör efterlevnaden mätbar istället för abstrakt.
Ansvarsfördelningen bör vara skriftlig från start, eftersom GDPR är en styrelsenivåfråga som kräver tydligt styrelseansvar för GDPR. IT-drift äger den tekniska insamlingen, dataskyddsombudet äger dokumentationen mot GDPR, och systemägaren för respektive verksamhetssystem ansvarar för att accessrecensioner faktiskt genomförs på schema.
Trustview-perspektivet på loggning som administrativ börda
Det vanligaste misstaget jag ser hos organisationer som hanterar känsliga personuppgifter är inte tekniskt. Det är att loggpolicyn och registerförteckningen lever i separata dokument som ingen uppdaterar samtidigt. Resultatet blir att loggningen ser bra ut på pappret men inte går att koppla till en faktisk DPIA eller till en specifik behandling när tillsynsmyndigheten frågar.
Det andra vanliga problemet är accessrecensioner som aldrig blir av, trots att de står med i policyn. Utan ett system som påminner och håller ägarskapet tydligt blir de en engångsinsats snarare än en rutin. En plattform som binder ihop registerförteckning, incidentlogg och uppföljning av åtgärder på ett ställe gör det svårare att tappa den kopplingen, eftersom dokumentationen och ansvaret syns i samma flöde istället för i tre olika system.
— Jesper
Så stöttar Trustview er dokumentation av åtkomstloggning
Trustview är alternativet till spretiga Excel-ark och separata Word-dokument när loggpolicy, registerförteckning och DPIA ska hänga ihop, inte leva som tre skilda projekt som glider isär över tid.
Plattformen samlar registerförteckningen, incidentloggen och er uppföljning av åtgärder på ett ställe, vilket gör det enklare att visa en tillsynsmyndighet exakt var loggningen är dokumenterad och varför retentiontiden valts som den är. Färdiga mallar för DPIA och incidenthantering sparar timmar jämfört med att bygga strukturen från grunden, och delegeringsfunktionerna gör det tydligt vem som äger vilken uppgift, från IT-drift till dataskyddsombud. Se hur ni kan komma igång genom att titta på exempel på dataskyddsverktyg för GDPR-efterlevnad och boka en genomgång av hur er organisation kan strukturera loggdokumentationen redan denna kvartal.
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.
Källor
- EUR-Lex — NIS2 Directive (text och relevans för EEA)
- IT-Juridik — GDPR tekniska och organisatoriska åtgärder (TOMs)
- NIS2-Templates.com — What NIS2 CIR 2024/2690 Actually Requires for Logging
