PII i säkerhetsloggar: playbook för GDPR, NIS2 och DORA

En säkerhetsanalytiker öppnar SIEM klockan 02:17. Larmet ser först rutinmässigt ut: flera misslyckade inloggningar, en lyckad session från en ovanlig IP-adress och därefter en kraftig ökning av API-anrop mot en exportfunktion för kunddata. Inom några minuter är incidentkanalen full. Informationssäkerhetschefen vill veta om det rör sig om ett kontoövertagande. Juridikfunktionen frågar om loggarna innehåller personuppgifter. Dataskyddsombudet frågar om användar-ID, IP-adress, enhetsidentifierare och begärda URL:er i SIEM omfattas av integritetsinformationen och förteckningen över behandlingar. Chefen för regelefterlevnad frågar om loggarna måste bevaras för regulatorisk rapportering. Kundansvariga frågar om en kund kan begära radering av samma loggposter i morgon.

Det är här många organisationer upptäcker att säkerhetsloggning och dataskyddsstyrning har byggts som separata världar.

Säkerhetsteam vill ha detaljerade loggar, långa bevarandetider, oföränderlig lagring och snabb åtkomst. Dataskyddsteam vill ha uppgiftsminimering, ändamålsbegränsning, rollbaserad åtkomst, strikt bevarandestyrning och radering när uppgifterna inte längre behövs. Incidenthanterare vill bevara bevisunderlag exakt som det såg ut. Ansvarsskyldighet enligt GDPR kräver att organisationen kan förklara varför personuppgifter finns där, vem som har haft åtkomst till dem och hur länge de sparas. NIS2 och DORA ökar kraven på skyndsamhet, eftersom väsentliga och viktiga entiteter samt finansiella organisationer behöver tillräckligt underlag för att klassificera incidenter, rapportera dem i tid och visa effektiv IKT-riskhantering.

Den obekväma sanningen är enkel: säkerhetsloggar är ofta lagringsplatser för personuppgifter. Autentiseringsloggar kan innehålla användarnamn, e-postadresser, IP-adresser, enhetsfingeravtryck och geolokaliseringsdata. Applikationsloggar kan exponera URL:er, söksträngar, fragment av nyttolaster, ärendenummer och meddelandeinnehåll. EDR- och molnloggar kan innehålla värdnamn kopplade till anställda, filsökvägar med namn, sessionsidentifierare och administratörsåtgärder. IAM-loggar kan avslöja privilegieändringar, gruppmedlemskap och misslyckade åtkomstförsök till känsliga system.

Om loggar innehåller PII är de inte längre enbart en ISO 27001-fråga om loggning. De blir en fråga om dataskydd, bevarande, bevisunderlag, incidentrapportering och leverantörsstyrning. Clarysec behandlar styrning av PII i säkerhetsloggar som ett efterlevnadsproblem över flera regelverk, inte som ett problem med verktygskonfiguration.

Informationssäkerhetschefens verkliga dilemma: detekteringsunderlag kontra uppgiftsminimering

Informationssäkerhetschefen i 02:17-scenariot står inför en verklig operativ konflikt. Om loggarna är för tunna kan SOC inte detektera kompromettering, återskapa tidslinjer eller stödja rapportering enligt NIS2 och DORA. Om loggarna är för omfattande kan organisationen samla in fler personuppgifter än nödvändigt, bevara dem för länge, exponera dem för för många administratörer eller brista i stödet för rättigheter och transparensskyldigheter enligt GDPR.

GDPR definierar personuppgifter brett som information som avser en identifierad eller identifierbar person. Behandling omfattar insamling, lagring, användning, utlämnande, radering och förstöring. I praktiken kan loggar som innehåller IP-adresser, användar-ID, enhetsidentifierare eller aktivitetsloggar vara personuppgifter beroende på sammanhang. GDPR-principerna kräver laglig, korrekt och transparent behandling, ändamålsbegränsning, uppgiftsminimering, lagringsminimering, riktighet, integritet och konfidentialitet samt ansvarsskyldighet.

Styrningsfrågan är inte: ”Kan vi någonsin logga personuppgifter?” Den bättre frågan är: ”Vilken PII behöver vi logga för säkerhet, incidenthantering och efterlevnad, vilken rättslig grund stödjer det, vilka skyddsåtgärder gäller och när måste uppgifterna raderas, anonymiseras eller omfattas av ett godkänt bevarande?”

Clarysecs policybibliotek för dataskydd i företag adresserar denna spänning direkt. Policy för dataskydd och integritet, Krav för genomförande av policyn, klausul 6.2.1 anger:

Endast data som är nödvändiga för ett specifikt och legitimt affärssyfte får samlas in och behandlas.

För SME anges samma princip i Policy för dataskydd och integritet – SME, Krav för genomförande av policyn, klausul 6.2.1:

Endast de minsta nödvändiga personuppgifterna ska samlas in och bevaras.

Den meningen ska styra varje designbeslut om loggning. Är varje fält i varje loggkälla nödvändigt för ett definierat säkerhetsmässigt, operativt, rättsligt eller avtalsmässigt syfte?

Varför ISO 27701 förändrar samtalet om loggning

ISO/IEC 27001:2022 ger ledningssystemet: omfattning, intressenter, riskbedömning, riskbehandling, operativ styrning, övervakning, internrevision och ständig förbättring. ISO/IEC 27002:2022 ger praktisk vägledning om kontroller för loggning, övervakning, skydd av PII, bevisinsamling, skydd av dokumenterad information, radering, åtkomstkontroll och leverantörshantering. ISO/IEC 27701 utvidgar styrningsmodellen till ledningssystem för integritetsinformation genom fokus på PII-personuppgiftsansvariga och PII-personuppgiftsbiträden, dataskyddsroller, register över behandling av PII, inbyggt dataskydd, hantering av rättigheter och skyldigheter för personuppgiftsbiträden.

För säkerhetsloggar är ISO 27701 viktig eftersom den tvingar fram dataskyddsspecifika frågor som säkerhetsteam ibland hoppar över:

• Behandlar loggkällan PII som personuppgiftsansvarig, personuppgiftsbiträde, gemensamt personuppgiftsansvarig eller underbiträde?
• Ingår loggdata i förteckningen över behandlingsaktiviteter?
• Vet organisationen vilka loggfält som innehåller PII?
• Är PII i loggar kopplad till regler för bevarande och radering?
• Informeras kunder, där organisationen är personuppgiftsbiträde, om åtkomstloggning av PII när detta krävs enligt avtal?
• Beaktas loggar vid svar på begäranden om tillgång, radering eller begränsning?
• Bedöms PII-incidenter mot rapporterings- och anmälningsutlösare inom dataskydd, cybersäkerhet och finanssektorn?

Clarysecs Policy för säkerhet och åtkomstkontroll för PII omsätter detta i operativa krav. Från Loggning och övervakning, klausul 4.6.1:

[Båda] Systemägaren / applikationsägaren SKA definiera loggningsomfattning för personuppgifter för autentiseringshändelser, åtkomsthändelser, privilegierade åtgärder, exportaktivitet för PII och väsentliga konfigurationsändringar i REG12 före produktionsanvändning eller väsentlig ändring.

Klausul 4.6.2 sluter därefter kretsen mellan loggning, åtkomstkontroll och bevarande:

[Båda] Informationssäkerhetsansvarig SKA säkerställa att loggar som innehåller PII har begränsad åtkomst och är kopplade till en godkänd bevarande- eller raderingsregel i REG02 eller REG12 innan loggövervakning inleds.

Det gör PIMS-styrning praktiskt genomförbar. REG12 definierar vilken PII-loggning som är tillåten och krävs. REG02 identifierar var PII finns, inklusive i loggar. Regler för bevarande och radering är inte administrativt efterarbete. De blir förutsättningar för produktionsloggning.

Säkerhetsloggar är poster, bevisunderlag och behandling av PII

En mogen organisation bör inte behandla loggar som tekniskt avfall som kan kastas. Loggar är poster. Under en incident kan de bli rättslig bevisning. När de innehåller PII är de också dataskyddsstyrda behandlingsdata.

Clarysecs Loggnings- och övervakningspolicy definierar förväntningar på loggnormalisering. Från Styrningskrav, klausul 5.1.4:

Krav på loggformat och normalisering (t.ex. tidsstämpel, användar-ID, händelsetyp, käll-IP)

Det är exakt de fält som gör loggar användbara för incidenthantering. Det är också de fält som ofta gör loggar till personuppgifter. Samma företagspolicy markerar vad som aldrig ska förekomma, från Styrningskrav, klausul 5.3.3:

Lagring av känsliga data i klartext (t.ex. lösenord, kryptografiska hemligheter)

Poängen är inte att loggar ska undvika alla identifierare. Poängen är att identifierare måste vara avsiktliga, skyddade och motiverade. Lösenord, hemligheter, fullständiga token och onödiga nyttolaster ska inte loggas. Användar-ID, IP-adresser och händelsemetadata kan vara nödvändiga, men de kräver kontroller.

För SME placerar Clarysecs Loggnings- och övervakningspolicy – SME dataskyddsgranskning i rollstrukturen. Från Roller och ansvar, klausul 4.3.1, krävs att organisationen:

Verifierar att loggdata som avser personuppgifter eller känslig information hanteras i enlighet med GDPR och andra dataskyddslagar.

SME-versionen ger också ett tydligt krav på baslinje för bevarande. Från Styrningskrav, klausul 5.2.1:

Loggar ska bevaras i minst 12 månader om inte en längre bevarandetid krävs enligt lag eller avtal, eller är motiverad som del av en aktiv incident eller rättslig tvist.

Och den anger förväntan på skydd, från Styrningskrav, klausul 5.3.1:

Loggar ska lagras på skrivskyddade platser, och åtkomst ska begränsas till behörig personal.

För incidenthantering i företag kräver Policy för bevisinsamling och forensik, Krav för genomförande av policyn, klausul 6.3.1:

Loggar från brandväggar, SIEM, agenter för slutpunktssäkerhet, identitets- och åtkomsthantering (IAM) och molnplattformar ska exporteras och lagras i oföränderliga format.

SME-versionen lägger till en proportionalitetsspärr. Policy för bevisinsamling och forensik – SME, Riskbehandling och undantag, klausul 7.2.1 anger:

Minimera omfattningen av insamlingen; samla endast in det som är nödvändigt.

Det är kärnan i dataskyddsmedveten loggning: bevara det som är nödvändigt, visa varför det är nödvändigt, begränsa vem som kan se det och radera det när det godkända ändamålet upphör.

Clarysecs kontrollmodell för dataskyddssäkert bevisunderlag

I Zenith Blueprint: An Auditor’s 30-Step Roadmap placerar Clarysec loggning i fasen Controls in Action, steg 19: Technological Controls I. Guiden förklarar kontrollförväntan i ISO/IEC 27002:2022:

A.8.15 – Loggning: ”Loggar som registrerar aktiviteter, undantag, fel och andra relevanta händelser bör skapas, lagras, skyddas och analyseras.”

Samma steg instruerar organisationer att generera loggar för viktiga händelser, lagra dem säkert så att de inte kan ändras, bevara dem under en definierad period och analysera dem genom en SIEM- eller granskningsprocess. Det kopplar också loggning till incidentanmälan enligt GDPR, DORA-incidentposter, NIS2-riskhantering och COBIT-analys av säkerhetsloggar.

Men loggning räcker inte i sig. I samma Controls in Action-fas, steg 19, behandlar Zenith Blueprint radering. Den varnar för att data som bevaras längre än det operativa värdet ökar exponering och regulatorisk risk, och den pekar uttryckligen ut säkerhetskopior, ögonblicksbilder och arkiv. Detta är viktigt eftersom en bevaranderegel i SIEM saknar verkan om replikerade loggarkiv eller objektlagringsytor i molnet bevarar samma PII på obestämd tid.

I steg 23: Organizational controls behandlar Zenith Blueprint insamling av bevisunderlag. Den anger att incidentunderlag måste identifieras, samlas in och bevaras på ett sätt som är rättsligt godtagbart, tillförlitligt och anpassat till utredningsbehoven. Den betonar också en operativ realitet: bevisunderlag går ofta förlorat under de första minuterna av incidenthantering när loggar roteras, system startas om eller administratörer ändrar komprometterade konton innan ögonblicksbilder har tagits.

Steg 23 behandlar också dataskydd och skydd av PII. Guiden beskriver PII som en livscykelfråga som kräver datamedvetenhet, klassificering, åtkomstkontroll, maskning, radering, kryptering och leverantörsskyldigheter. För loggar innebär det att SIEM, EDR, molnbaserad loggningsplattform och ärendehanteringssystem måste ingå i PII-förteckningen.

Mappning mellan efterlevnadskrav för PII i loggar

Zenith Controls: The Cross-Compliance Guide mappar ISO/IEC 27002:2022 kontroll 8.15, Loggning, till relaterade kontroller som är avgörande för styrning av PII. Dessa relationer visar varför loggning inte bara är en SOC-fråga.

Zenith Controls mappar också Loggning till ISO/IEC 27002:2022 klausul 8.15, ISO/IEC 27035-1 och ISO/IEC 27035-2 för incidenthantering, ISO/IEC 27701 för loggning av behandlingsaktiviteter för PII, ISO/IEC 27017 för revisionsloggar i moln, ISO/IEC 27018 för åtkomstloggning av PII i moln, ISO/IEC 27005 för risker vid otillräcklig loggning, ISO/IEC 27033 för loggning av nätverksaktivitet och ISO/IEC 15408-2 för revisionsfunktionalitet i utvärderade produkter.

Specifikt för dataskydd mappar Zenith Controls ISO/IEC 27002:2022 kontroll 5.34, Dataskydd och skydd av PII, till tillgångsförteckning, datamaskering, molntjänster, klassificering, informationsöverföring, åtkomstkontroll, identitetshantering och säkerhetsgranskning av projekt och ändringar. För ett program för loggstyrning blir dessa kopplingar praktiska designkrav:

• För in logglager som platser där PII finns.
• Maskera eller tokenisera PII där fullständiga identifierare inte är nödvändiga.
• Granska molnbaserade loggningstjänster och SIEM-leverantörer enligt kontroller för moln och leverantörer.
• Klassificera loggar som innehåller PII som känsliga poster.
• Styr export och överföringar av loggar som PII-överföringar.
• Begränsa loggåtkomst genom identitetskontroller och kontroller för privilegierad åtkomst.
• Granska ändringar i applikationsloggning före produktionsrelease.

GDPR, NIS2 och DORA: en logg, tre regulatoriska perspektiv

Samma loggpost kan bedömas olika enligt GDPR, NIS2 och DORA.

Enligt GDPR frågar organisationen om loggposten innehåller personuppgifter, vilken rättslig grund som stödjer behandlingen, om uppgifterna är nödvändiga, hur länge de bevaras, vem som kan komma åt dem, om de lämnas ut till personuppgiftsbiträden eller kunder och om de måste beaktas i en rättighetsbegäran eller bedömning av personuppgiftsincident.

Enligt NIS2 frågar organisationen om loggar stödjer cybersäkerhetsriskhantering, incidenthantering, verksamhetskontinuitet, åtkomstkontroll, säkerhet i leveranskedjan och bedömning av kontrolleffektivitet. NIS2 Article 20 gör ledningsorgan ansvariga för att godkänna och övervaka riskhanteringsåtgärder för cybersäkerhet. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker utveckling, sårbarhetshantering, effektivitetsbedömning, cyberhygien, åtkomstkontroll och tillgångshantering. Article 23 inför stegvis rapportering av betydande incidenter, inklusive tidig varning inom 24 timmar, anmälan inom 72 timmar och slutrapport inom en månad.

Enligt DORA måste finansiella entiteter driva ett dokumenterat ramverk för IKT-riskhantering. DORA Article 5 tilldelar ansvaret till ledningsorganet. Article 10 behandlar detektering. Article 17 kräver en process för hantering av IKT-relaterade incidenter. Article 18 omfattar klassificering av IKT-relaterade incidenter och cyberhot. Article 19 behandlar rapportering av större IKT-relaterade incidenter. Loggar stödjer detektering, klassificering, rotorsaksanalys, konsekvensbedömning, respons, återhämtning och bevisunderlag för åtgärdande.

En mer detaljerad kontrollöversikt hjälper informationssäkerhetschefen att motivera loggning utan att luta sig mot vaga formuleringar som ”vi behöver det för säkerheten”.

Bygg en loggningsomfattning för PII i REG12

En Clarysec-kund skulle hantera SIEM-incidenten klockan 02:17 innan den någonsin inträffar. Organisationen börjar med en kundvänd applikation som behandlar kontodata. Före produktion använder applikationsägaren REG12 för att definiera loggningsomfattning för personuppgifter. Målet är att fånga tillräckligt många händelser för säkerhet och regulatoriskt underlag utan att logga onödiga personuppgifter eller nyttolastinnehåll.

Därefter bekräftar dataskyddsansvarig om organisationen agerar som personuppgiftsansvarig, personuppgiftsbiträde eller båda för varje loggkälla. Om organisationen är personuppgiftsbiträde kan kundens avtalsinstruktioner och utlämnanden om underbiträden begränsa åtkomst till och delning av loggar. Om organisationen är personuppgiftsansvarig måste integritetsinformation, rättslig grund och hantering av rättigheter adresseras.

Dataägaren uppdaterar därefter REG02 så att den omfattar aktiva logglager, SIEM-index, arkiv, säkerhetskopior och tillfälliga forensiska exporter. Detta ligger i linje med Policy för bevarande, radering och bortskaffning av PII, Säkerhetskopior, arkiv, repliker, loggar och tillfälliga filer, klausul 4.4.1:

[Båda] Systemägaren / applikationsägaren SKA identifiera aktiva lagringsplatser, arkiv, säkerhetskopior, repliker, loggar, stagingområden och tillfälliga filer som innehåller PII i REG02 före produktionssättning och vid varje årlig bevarandegranskning.

Policy för databevarande och bortskaffning bör därefter samordna verksamhetens bevaranderegler med rättsliga, avtalsmässiga och bevisrelaterade bevarandekrav.

Slutligen konfigurerar säkerhetsteamet SIEM så att lösenord, hemligheter och nyttolaster tas bort eller maskas före inhämtning. Loggar som innehåller PII tilldelas begränsade index. Bevarande tillämpas automatiskt om inte en incident eller juridiskt bevarande godkänns. Raderingsåtgärder loggas. Forensiska exporter kräver godkännande och spårning av beviskedja. Kontrollpaneler visar pseudonymiserade identifierare där full identitet inte behövs. Historisk loggåterhämtning testas vid internrevisioner.

Detta är skillnaden mellan att säga ”vi loggar för säkerhet” och att kunna visa ”vi loggar endast det som är nödvändigt, skyddar det, bevarar det enligt godkända regler och kan använda det som bevisunderlag utan att bryta mot dataskyddsskyldigheter”.

DSAR, radering och loggar: besluta innan begäran kommer

En av de svåraste frågorna är om loggar måste sökas igenom, lämnas ut eller raderas med anledning av en begäran om tillgång till personuppgifter eller begäran om radering. Svaret beror på roll, ändamål, rättslig grund, genomförbarhet, undantag och bevarandeskyldigheter. Men styrningsprocessen kan inte uppfinnas begäran för begäran.

Policy för hantering av registrerades rättigheter, Identitetsverifiering, omfattning och utvärdering, klausul 4.2.3 anger:

[Personuppgiftsansvarig] Processägaren / verksamhetsägaren SKA identifiera relevanta system, poster, ändamål, PII-kategorier, mottagare och bevarandebegränsningar från REG02 innan fullgörande utvärderas.

Det innebär att loggar måste finnas i REG02 med tydlig metadata: vilka PII-kategorier de innehåller, vilket ändamål de tjänar, vilken bevarandebegränsning som gäller och om en begäran kan uppfyllas genom direkt utlämnande, sammanfattad åtkomst, begränsning, radering vid bevarandetidens slut eller avslag baserat på en dokumenterad rättslig grund.

Clarysec rekommenderar en modell i tre nivåer:

1. Operativa loggar med låg integritetspåverkan, till exempel systemhändelseloggar som använder pseudonyma användar-ID, kan vara sökbara och lämnas ut där det är lämpligt.
2. Säkerhetsloggar med hög säkerhetskänslighet, till exempel SIEM-korrelationsdata eller sammanhang från hotinformation, kan kräva filtrering, sammanfattat utlämnande eller begränsning för att undvika exponering av detekteringslogik eller tredjepartsdata.
3. Forensisk bevisning under aktiv incident eller juridiskt bevarande bör inte ändras slentrianmässigt. Radering kan skjutas upp eller begränsas när det är rättsligt motiverat, med beslutet dokumenterat av dataskydds- och juridikintressenter.

Om dataskyddsombudet och SOC diskuterar varje DSAR från början blir organisationen inkonsekvent och långsam. Om REG02 och REG12 underhålls blir hanteringen av rättigheter underlagsbaserad.

Incidentanmälan och incidentrapportering: en händelse, flera klockor

Larmet klockan 02:17 kan starta flera tidsfrister. Bedömning av personuppgiftsincident enligt GDPR kan kräva anmälan till tillsynsmyndighet när risktrösklar uppfylls. Rapportering av betydande incident enligt NIS2 kan kräva en tidig varning inom 24 timmar, anmälan inom 72 timmar och slutrapport. DORA kan kräva rapportering av större IKT-relaterad incident i initiala, mellanliggande och slutliga steg. Kundavtal kan ha ännu kortare underrättelsefrister.

Clarysecs Policy för hantering av PII-incidenter och personuppgiftsincidenter adresserar detta problem med flera utlösare direkt. Från Klassificering och bedömning av personuppgiftsincident, klausul 4.2.6:

[Villkorligt] Dataskyddsansvarig / PIMS-ansvarig SKA utvärdera tillämpliga rättsliga, sektorspecifika, finanssektorsrelaterade, cybersäkerhetsrelaterade, avtalsmässiga, kundrelaterade och tjänstemottagarrelaterade rapporteringsutlösare för varje personuppgiftsincident med hög påverkan och registrera utfallet av tillämplighetsbedömningen i REG01, REG08 och REG10.

Under triagering bör organisationen fråga:

• Fick angriparen åtkomst till personuppgifter, eller endast metadata?
• Exponerade loggarna ytterligare PII för obehöriga användare?
• Behövs loggar för att fastställa berörda personer, system och tidsperiod?
• Lagras loggar oföränderligt och med begränsad åtkomst?
• Har ett incidentbevarande pausat radering för relevanta loggar?
• Påverkas kunder där organisationen är personuppgiftsbiträde, kunder i finanssektorn eller tjänstemottagare?
• Vilka rapporteringsfrister gäller, och vem ansvarar för varje underrättelse?

Väl styrda loggar påskyndar rapportering eftersom de ger beslutsfattare tillförlitliga fakta. Bristfällig loggning orsakar förseningar. Överloggning skapar dataskyddsrisk. Rätt lösning är riktad, skyddad och mappad loggning.

Leverantörs- och molnloggning: problemet med personuppgiftsbiträden som döljer sig i ditt SIEM

De flesta organisationer lagrar inte alla loggar i infrastruktur som de helt kontrollerar. Loggar flödar till SIEM-plattformar, EDR-portaler, molnbaserade loggningstjänster, observability-plattformar, ärendehanteringssystem och leverantörer av Managed Detection and Response (MDR). Enligt GDPR kan dessa leverantörer vara personuppgiftsbiträden eller underbiträden. Enligt NIS2 och DORA kan de också vara direkta leverantörer, IKT-tredjepartstjänsteleverantörer, leverantörer av hanterade tjänster eller leverantörer av hanterade säkerhetstjänster.

NIS2 Article 21 omfattar uttryckligen säkerhet i leveranskedjan, leverantörssårbarheter och leverantörers övergripande cybersäkerhetspraxis. DORA lägger till detaljerade krav på IKT-tredjepartsrisker för finansiella entiteter, inklusive leverantörsgranskning före avtal, informationsregister, revisionsrätt och åtkomsträtt, incidentstöd, datalagringsplats, dataskyddsklausuler, exitstrategier och avtalsbestämmelser för kritiska eller viktiga funktioner.

För PII i säkerhetsloggar bör leverantörsgranskningar omfatta följande frågor:

Ett SIEM-avtal är inte bara en programvaruprenumeration. Det är ett beroende för behandling av PII och incidentunderlag.

Revisionsperspektiv: hur granskare testar PII i säkerhetsloggar

En bra revisor accepterar inte påståendet att ”loggar är skyddade”. Revisorn testar kedjan från policy till konfiguration, underlag och granskning.

Ett praktiskt revisionstest är enkelt men avslöjande: be SOC hämta en loggpost från tio månader tillbaka som visar en privilegierad åtkomständring i en molnplattform, visa vem som haft åtkomst till loggen, visa att den inte har ändrats, visa bevaranderegeln som tillät att den fanns kvar, visa vilka PII-fält den innehåller och visa hur den skulle hanteras i en DSAR eller incidentrapport. Om teamet inte kan svara samlat över säkerhet, dataskydd och regelefterlevnad är styrningen ofullständig.

Vanliga iakttagelser vid revision av PII i loggar

Clarysec ser ofta samma mönster:

• Applikationsteam loggar fullständiga nyttolaster från begäranden för felsökning, inklusive namn, e-postadresser, kontonummer eller meddelandeinnehåll.
• SIEM-index är öppna för breda IT-administratörsgrupper i stället för begränsade SOC-roller.
• Loggbevarande sätts globalt utan hänsyn till PII-känslighet, kundavtal eller regler för incidentbevarande.
• Molnleverantörsloggar är aktiverade, men leverantörsadministratörers åtkomst till kundens loggdata granskas inte.
• DSAR-rutiner nämner inte loggar, SIEM-ärenden eller forensiska exporter.
• Incidenthanteringsplaner bevarar bevisunderlag, men dataskyddsteam deltar inte i klassificeringen.
• Säkerhetskopior och arkiv bevarar PII i loggar längre än SIEM.
• Utvecklare kan ändra loggnivåer i produktion utan dataskydds- eller säkerhetsgranskning.
• Testmiljöer tar emot produktionsloggar med personuppgifter.
• Organisationen har rapporteringsskyldigheter enligt NIS2 eller DORA men kan inte snabbt hämta tillförlitligt underlag.

Dessa iakttagelser beror sällan på dåliga avsikter. De beror på silouppdelat ägarskap. Säkerhetsloggar ligger mellan SOC, plattformsteknik, dataskydd, juridik, regelefterlevnad, revision och leverantörer. Om ingen äger hela livscykeln uppstår luckor.

En Clarysec-checklista för revisionsklar loggstyrning

Använd denna checklista som praktisk utgångspunkt för nästa styrningsgranskning:

1. Definiera vilka loggkällor som kan innehålla PII: IAM, applikation, API-gateway, SIEM, EDR, moln, databas, nätverk, fysiskt tillträde och ärendehantering.
2. Registrera varje logglager i REG02, inklusive aktiva lagringsplatser, arkiv, säkerhetskopior, repliker och tillfälliga forensiska exporter.
3. Definiera loggningsomfattning för PII i REG12 före produktionsanvändning eller väsentliga ändringar.
4. Identifiera ändamål och rättslig grund för behandling av säkerhetsloggar.
5. Förbjud lösenord, hemligheter, fullständiga token och onödiga nyttolaster i loggar.
6. Använd maskning, hashning eller pseudonymisering där fullständiga identifierare inte krävs.
7. Begränsa åtkomst till loggar som innehåller PII efter roll, med granskning av privilegierad åtkomst.
8. Lagra högt värderade loggar i oföränderliga eller skrivskyddade format.
9. Definiera bevarande per loggtyp, rättslig skyldighet, avtal, incidentbehov och dataskyddsrisk.
10. Inför incidentbevarande med godkännande, omfattning och utgångstid.
11. Inkludera loggar i bedömningslogiken för DSAR och radering.
12. Granska SIEM-, EDR-, moln- och MDR-leverantörer som personuppgiftsbiträden eller IKT-tredjeparter.
13. Testa historisk återhämtning och underlagets integritet.
14. Mappa loggning till rapporteringsbehov enligt GDPR, ISO 27701, NIS2, DORA, NIST CSF och COBIT.
15. Utbilda SOC-, dataskydds- och applikationsteam i vad som får och inte får loggas.

Denna checklista gör dataskyddsmedveten loggning till en repeterbar kontrollprocess.

Från dilemma till förtroende på styrelsenivå

NIS2 gör cybersäkerhet till ett ledningsansvar. DORA gör ledningsorganet ansvarigt för IKT-riskhantering, strategi för digital operativ motståndskraft, datakonfidentialitet, incidentkommunikation och policyer för IKT-tredjepartstjänster. ISO/IEC 27001:2022 kräver att högsta ledningen anpassar ledningssystemet för informationssäkerhet till verksamhetsmål, tilldelar ansvar, tillhandahåller resurser och driver ständig förbättring.

PII i säkerhetsloggar är därför inte en smal teknisk detalj. Det är en förtroendefråga på styrelsenivå. Organisationens förmåga att detektera incidenter, skydda personuppgifter, bevara bevisunderlag, svara kunder, uppfylla tillsynsmyndigheters krav och återställa verksamheten beror på loggningsbeslut som fattas långt före incidenten.

De bästa styrningsprogrammen väljer inte mellan dataskydd och säkerhet. De definierar den minsta loggning som krävs för robust säkerhet, skyddar den loggningen som känslig PII där det krävs och kopplar den till bevarande, bevisunderlag, hantering av rättigheter och leverantörsskyldigheter.

Nästa steg med Clarysec

Om dina SIEM-, IAM-, EDR- eller molnloggar innehåller personuppgifter är det dags att styra dem medvetet.

Clarysec kan hjälpa dig att:

• Bygga en loggningsomfattning för PII med REG12 och anpassa den till Policy för säkerhet och åtkomstkontroll för PII.
• Inventera logglager, arkiv, säkerhetskopior och forensiska exporter med REG02 och Policy för bevarande, radering och bortskaffning av PII.
• Anpassa loggning, övervakning, bevisunderlag och dataskyddskontroller med Zenith Blueprint.
• Mappa dina kontroller över GDPR, ISO 27701, NIS2, DORA, NIST CSF och COBIT med Zenith Controls.
• Förbereda revisionsklart underlag för ISO-, dataskydds-, NIST-, COBIT-, NIS2- och DORA-granskningar.

Börja med ett högrisksystem: din IAM-plattform, SIEM eller kundvända applikation. Identifiera vilken PII som hamnar i loggarna, varför den behövs, vem som kan komma åt den, hur länge den bevaras och hur den skulle användas under en incident eller rättighetsbegäran. Den enda övningen visar om ditt nuvarande loggningsprogram bara är operativt, eller om det verkligen är revisionsklart.