Dataskyddsstyrning för session replay enligt GDPR och ISO 27701

Demon som gjorde produktinsikt till dataskyddsunderlag

Demoskärmen såg ut som ett genombrott. Sarah, CISO på ett snabbväxande SaaS-bolag, såg produktteamet spela upp en verklig introduktionssession från deras nya analysplattform. Markören rörde sig över gränssnittet, en användare tvekade vid steg tre, klickade tillbaka två gånger, öppnade en hjälpruta och avbröt sedan flödet.

Produktchefen var entusiastisk. Session replay skulle visa exakt var kunder fastnade. Heatmaps skulle visa vilka fält som skapade friktion. Kraschdiagnostik skulle visa utvecklingsteamet vilka webbläsare som fallerade. Mobiltelemetri skulle hjälpa teamet att prioritera åtgärder efter enhetsversion. Det såg ut som en guldgruva för användarupplevelsen.

Sedan såg Sarah vad verktyget faktiskt hade fångat.

En användare skrev av misstag ett lösenord i användarnamnsfältet. En annan klistrade in ett nationellt ID-nummer i ett fritextfält. En supportagent öppnade ett kundkonto under felsökning och exponerade finansiella uppgifter på skärmen. Kraschloggar innehöll e-postadresser, IP-adresser, routningsnamn, autentiseringstillstånd, enhetsidentifierare och funktionsflaggor som avslöjade kundens interna arbetsflöde.

Analysleverantören kallade sig personuppgiftsbiträde. Kundavtalet angav att personuppgifter i produktionsmiljö inte fick användas för analys utan godkännande. Integritetsmeddelandet angav endast att företaget använde analys för att förbättra tjänsten. Det nämnde inte session replay, beteendeövervakning, enhetsidentifierare, maskning, lagringstid, mottagare eller internationella överföringar.

Produktteamet såg ofarliga driftdata. Sarah såg ostrukturerade, omaskerade och ostyrda personuppgifter (PII) i en molnplattform med bred intern åtkomst och oklar rättslig grund.

Det är det verkliga problemet med produkttelemetri och dataskyddsstyrning för session replay. Risken är inte att telemetri finns. Risken är att den behandlas som tekniskt spill med låg risk i stället för som en styrd behandlingsaktivitet som berör rättslig grund, integritetsmeddelande, DPIA-screening, leverantörsavtal, maskning, åtkomstkontroll, lagringstid, incidenthantering och revisionsunderlag.

Enligt ISO/IEC 27701:2025 behöver organisationer ett Privacy Information Management System, PIMS, som behandlar dataskydd som en operativ modell. Enligt GDPR måste personuppgiftsansvariga kunna visa efterlevnad av principer som laglighet, korrekthet, öppenhet, ändamålsbegränsning, uppgiftsminimering, lagringsminimering, riktighet, konfidentialitet och ansvarsskyldighet. Session replay och produkttelemetri ligger direkt i denna ansvarszon eftersom de ofta övervakar hur identifierbara personer beter sig i en digital tjänst.

Clarysecs metod är att lyfta ut telemetri ur skuggorna och placera den i en spårbar styrningskedja: förteckning, rollklassificering, rättslig grund, DPIA-screening, integritetsmeddelande, leverantörsbedömning, maskning, lagringstid, åtkomstkontroll, underlag och kontinuerlig granskning. Den kedjan stöds av Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Clarysecs PIMS-policyer och Zenith Controls: The Cross-Compliance Guide Zenith Controls.

Varför produkttelemetri inte bara är analys enligt GDPR

GDPR definierar personuppgifter brett, inklusive onlineidentifierare och information som avser en identifierad eller identifierbar fysisk person. Förordningen definierar även behandling brett och omfattar insamling, lagring, användning, utlämnande, radering och förstöring. Produkttelemetri kan därför bli behandling av personuppgifter när den innehåller, länkas till eller rimligen kan kopplas till användare, klientmiljöer, administratörer, anställda eller kunders slutanvändare.

Vanliga datapunkter i telemetri omfattar:

• användar-ID, e-postadresser, klientorganisations-ID och konto-ID
• IP-adresser, enhetsidentifierare, webbläsarfingeravtryck och mobila reklam-ID
• funktionsanvändning, klickvägar, skrolldjup, formulärinteraktion och felbeteende
• kraschdumpar, routningsnamn, fragment av API-payloads och diagnostikloggar
• inspelningar från session replay, DOM-ögonblicksbilder, tangenttryckningshändelser och heatmaps
• supportmetadata, skärmdumpar, skärminspelningar och användaråterkoppling
• prestandahändelser kopplade till konto, roll, geografi eller kundsegment

Dataskyddsfrågan fördjupas när telemetri avslöjar beteende. GDPR Article 3 kan gälla även för SaaS-leverantörer utanför EU när de erbjuder varor eller tjänster till personer i unionen eller övervakar deras beteende inom unionen. Session replay, heatmaps och produktanalys är ofta beteendeövervakning i vanlig mening, även när affärssyftet är produktförbättring snarare än annonsering.

GDPR Article 6 kräver rättslig grund för varje behandlingsändamål. Samtycke kan vara lämpligt när spårningen är frivillig, ingripande eller omfattas av lokala ePrivacy-regler. Berättigat intresse kan vara möjligt för begränsad telemetri, men endast efter bedömning av nödvändighet, proportionalitet och enskildas rättigheter och friheter. Avtal kan stödja telemetri som är strikt nödvändig för att tillhandahålla tjänsten, men inte varje produktoptimering eller användningsfall för session replay ryms utan vidare inom avtal som rättslig grund.

Risk kopplad till särskilda kategorier är också viktig. GDPR Article 9 begränsar behandling av uppgifter som avslöjar hälsa, biometriska uppgifter, politisk eller religiös uppfattning eller andra känsliga kategorier. Många SaaS-leverantörer antar att de inte samlar in sådana uppgifter, men upptäcker senare att kunder klistrar in dem i supportformulär, arbetsflödesfält, anteckningar, HR-register, beskrivningar av juridiska ärenden, medicinska anspråk eller skärmdumpar som fångas av verktyg för session replay.

Clarysecs Enterprise Data Protection and Privacy Policy Data Protection and Privacy Policy gör rättslig grund och uppgiftsminimering tydliga:

All behandling ska baseras på en giltig rättslig grund (t.ex. samtycke, avtal, rättslig skyldighet).

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.1.

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

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.2.1.

För mindre team kräver Data Protection and Privacy Policy-sme Data Protection and Privacy Policy - SME disciplin i behandlingsförteckningen:

Integritetssamordnaren ska upprätthålla ett register över alla behandlingsaktiviteter för personuppgifter, inklusive datakategorier, ändamål, rättslig grund och lagringstider.

Från avsnittet ”Styrningskrav”, policyklausul 5.2.1.

Den ger också produkt- och utvecklingsteam en tydlig baslinje för inbyggt dataskydd:

Inbyggt dataskydd och dataskydd som standard ska tillämpas i alla nya system och tjänster.

Från avsnittet ”Styrningskrav”, policyklausul 5.3.1.

Styrningskorrigeringen är enkel: fråga inte om telemetri är ”analys”. Fråga om det är en behandlingsaktivitet som innefattar PII, beteendeövervakning, profilering, leverantörsåtkomst, lagringstid och säkerhetskontroller.

Börja med tydliga roller enligt ISO 27701:2025

Dataskyddsstyrning enligt ISO/IEC 27701:2025 fungerar bäst när organisationer först definierar sin roll. Agerar ni som personuppgiftsansvarig och beslutar varför session replay används och vilka data som fångas? Är ni personuppgiftsbiträde och fångar telemetri för en kund enligt dokumenterade instruktioner? Är ni båda, beroende på funktion och kundkonfiguration?

Clarysecs PIMS-policyuppsättning använder rolltaggar för att göra detta operativt. ”Båda” gäller oavsett om organisationen agerar som personuppgiftsansvarig eller personuppgiftsbiträde. ”Personuppgiftsansvarig” gäller när organisationen bestämmer ändamål och medel. ”Personuppgiftsbiträde” gäller när behandlingen utförs enligt dokumenterade instruktioner.

En SaaS-leverantör kan vara personuppgiftsansvarig för telemetri som används för att förbättra den egna produkten, identifiera friktion i användarupplevelsen eller prioritera produktplanen. Samma leverantör kan vara personuppgiftsbiträde för telemetri som fångas i en kundstyrd arbetsyta där kunden bestämmer ändamålet. I sällsynta fall kan gemensamt personuppgiftsansvar uppstå när båda parter gemensamt bestämmer ändamål och medel. I andra kedjor kan leverantören vara underbiträde som hanterar telemetri för ett annat personuppgiftsbiträde.

Enterprise PII Processing Inventory and Lawful Basis Policy PII Processing Inventory and Lawful Basis Policy gör den första grinden konkret:

[Båda] Processägaren/verksamhetsägaren MÅSTE skapa en REG02-post i behandlingsförteckningen innan någon ny behandlingsaktivitet för PII påbörjas.

Från avsnittet ”Baslinje för behandlingsförteckning”, policyklausul 4.1.1.

För produkttelemetri ska REG02 inte innehålla en vag rad med ”analys”. Den ska separera ändamål och dataflöden.

ISO/IEC 27001:2022 stöder detta PIMS-arbete genom att ge organisationen struktur för kontext, krav från intressenter, omfattning, ledarskap, roller, riskbedömning, riskbehandlingsplanering, operativ styrning och externt tillhandahållna tjänster. ISMS frågar vilka tillgångar, risker, ägare, kontroller och underlag som finns. PIMS frågar vilka PII som behandlas, varför, i vilken roll, med vilka rättigheter, skyddsåtgärder och meddelanden.

Tillsammans förhindrar de den klassiska dataskyddsluckan där produktteam aktiverar spårning snabbare än styrningen hinner klassificera den.

DPIA-utlösare: när produktinsikt blir högriskbehandling

Inte varje telemetrihändelse kräver en fullständig DPIA. Men session replay och beteendeanalys kräver ofta DPIA-screening eftersom de kan innefatta systematisk övervakning, profilering, storskalig behandling, känsligt innehåll, sårbara användare, innovativ teknik eller väsentligt ändrad behandling.

Privacy Risk Assessment and DPIA Policy Privacy Risk Assessment and DPIA Policy är tydlig för personuppgiftsansvariga:

[Personuppgiftsansvarig] Processägaren/verksamhetsägaren MÅSTE hänskjuta behandling som innefattar storskalig, systematisk övervakning, profilering, automatiserade beslut, särskilda kategorier av PII, uppgifter om fällande domar eller överträdelser, sårbara registrerade, innovativ teknik eller väsentligt ändrad behandling till dataskyddsombudet/PIMS-ansvarig i REG04 innan behandlingen påbörjas.

Från avsnittet ”DPIA-utlösare och fastställande av krav”, policyklausul 4.2.2.

En DPIA-screening för session replay bör ställa praktiska frågor:

• Fångar sessionsuppspelningen formulärinmatning, sidinnehåll, chatttext, uppladdade dokument eller felpayloads?
• Sker maskning innan data lämnar webbläsaren, eller först efter inhämtning?
• Kan verktyget fånga lösenord, token, hemligheter, engångskoder eller betalningsfält?
• Är sessioner kopplade till namngivna användare, konton, IP-adresser eller enhetsidentifierare?
• Kan anställda söka i sessionsuppspelningar efter användare, kund, segment, fel, URL eller beteende?
• Använder leverantören data för analys, AI-träning, benchmarking eller produktförbättring?
• Förekommer internationella överföringar?
• Vilken lagringstid är konfigurerad, och kan radering verkställas per klientorganisation eller användare?
• Kan kunder inaktivera session replay, konfigurera maskning eller begära radering?
• Omfattas anställda, administratörer och kunders slutanvändare av meddelanden?
• Finns risk att uppgifter om barn, hälsodata, finansiella data eller HR-data fångas?

Enterprise Data Protection and Privacy Policy förstärker tröskeln för hög risk:

Hotmodellering och konsekvensbedömningar avseende dataskydd (DPIA:er) är obligatoriska för högriskbehandlingssystem.

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.3.4.

En viktig lärdom från Clarysecs revisioner är att risk med session replay inte bara är en dataskyddsfråga. Det är också en fråga om säkerhetsarkitektur. Om DOM-ögonblicksbilder fångar bearer tokens, interna ID, dolda fält eller känsliga kundarbetsflöden har organisationen skapat ett nytt datalager med högt skyddsvärde utanför sin normala perimeter för loggning, DLP och åtkomstgranskning.

Gör verktyget för session replay till en tillgång som kan granskas

Det snabbaste sättet att minska telemetririsk är att sluta behandla verktyg som osynlig produktinfrastruktur. I Zenith Blueprint, fasen Riskhantering, Step 9, ”Identifying Assets, Threats, and Vulnerabilities”, instruerar Clarysec organisationer att inventera tillgångar och registrera ägare, plats och klassificering. Den anger särskilt att personuppgiftstillgångar ska markeras för GDPR-relevans och att kritiska tjänstetillgångar ska noteras för potentiell NIS2-tillämplighet.

Blueprint beskriver en informationstillgång som allt av värde som kan skadas av en säkerhetsincident, inklusive information, programvara, molntjänster, tjänster/processer och tredjepartstjänster. För telemetristyrning blir varje analysplattform, leverantör av session replay, SDK, händelsepipeline, datasjö, kontrollpanel, export och lagringsplats för supportinspelningar en tillgång som kan granskas.

Detta kopplar dataskyddsstyrning till ISMS-underlag. Produkt-, dataskydds-, utvecklings- och revisionsteam kan hänvisa till samma post i stället för att upprätthålla separata beskrivningar.

Använd Zenith Controls som ryggrad för efterlevnad av flera regelverk

Clarysec använder Zenith Controls som en vägledning för efterlevnad av flera regelverk, inte som ersättning för officiella ramverk. För telemetri och session replay är de centrala temana i ISO/IEC 27002:2022 integritetsskydd och skydd av PII, styrning av molntjänster, leverantörsrelationer, datamaskering, tillgångsförteckning, klassificering, åtkomstkontroll och ändringshantering.

I Zenith Controls är ISO/IEC 27002:2022 control 5.34, Privacy and protection of PII, ankaret. Dess praktiska grund är datamedvetenhet:

Grunden för denna kontroll är datamedvetenhet. Organisationen måste veta vilka PII den samlar in, var de finns, varför de behandlas och vem som kan få åtkomst till dem.

Från Zenith Blueprint, fasen Controls in Action, Step 23, Control 5.34, Privacy and Protection of Personally Identifiable Information.

Zenith Controls mappar 5.34 till stödjande kontroller i ISO/IEC 27002:2022, såsom 5.9 förteckning över information och andra associerade tillgångar, 8.11 datamaskering, 5.23 informationssäkerhet vid användning av molntjänster, 5.12 klassificering av information, 5.14 informationsöverföring, 5.15 åtkomstkontroll, 5.16 identitetshantering, 5.19 informationssäkerhet i leverantörsrelationer, 5.8 informationssäkerhet i projektledning och 8.32 ändringshantering.

För datamaskering identifierar Zenith Controls ISO/IEC 27002:2022 control 8.11 som förebyggande och inriktad på konfidentialitet. Den kopplar också maskning till 8.3 begränsning av informationsåtkomst, 8.10 radering av information, 8.12 förebyggande av dataläckage, 8.24 användning av kryptografi och 8.33 testinformation. Detta är viktigt eftersom maskning för session replay inte får vara kosmetisk. Den måste utformas, testas och styrkas med underlag.

Data Masking and Pseudonymization Policy-sme Data Masking and Pseudonymization Policy - SME ger en enkel regel som även gäller produktanalys:

Skarpa personuppgifter får inte användas i testning, externa verktyg eller analys om det inte har godkänts formellt.

Från avsnittet ”Roller och ansvar”, policyklausul 4.4.1.

Ett praktiskt Clarysec-arbetsflöde för att godkänna session replay

Föreställ dig att produktteamet vill aktivera session replay för alla misslyckade checkout-sessioner i en fintech-app. Affärsnyttan är verklig: avbruten checkout påverkar intäkter och kundnöjdhet. Styrningsfrågan är om denna insikt kan samlas in lagligt, proportionerligt och säkert.

Steg 1: Skapa REG02 innan SDK:n tas i produktion

Använd REG02 enligt PII Processing Inventory and Lawful Basis Policy. Registrera ändamål, datakategorier, användarkategorier, källa, mottagare, lagringstid, överföringar, systemägare, rättslig grund och roll.

Skriv inte ”analys”. Skriv ”session replay för felsökning av misslyckad checkout och förbättring av konvertering”. Lista specifika fält, inklusive användar-ID, klientorganisations-ID, IP-adress, enhets-ID, klickhändelser, sidrutter, DOM-ögonblicksbilder, maskerade formulärfält, felkoder och status i betalningsflödet.

Steg 2: Fastställ rättslig grund

För grundläggande kraschdiagnostik och aggregerade prestandamått kan berättigat intresse vara försvarbart om organisationen dokumenterar nödvändighet, proportionalitet, skyddsåtgärder och användarnas förväntningar. För full session replay, särskilt på autentiserade sidor, kan samtycke vara tydligare när lokala regler eller behandlingens intrång kräver det.

En hybridmodell är ofta mer praktisk: använd berättigat intresse för begränsad, icke-intrusiv, maskerad telemetri och kräv uttryckligt opt-in eller aktivering på klientorganisationsnivå för session replay. Oavsett svar måste det dokumenteras och återspeglas i meddelanden, avtal och konfiguration.

Steg 3: Screena DPIA-utlösare i REG04

Session replay av misslyckad checkout kan innefatta finansiellt beteende, autentisering, betalningssidor och systematisk övervakning. Processägaren hänskjuter aktiviteten till dataskyddsombudet. Screeningen bedömer nödvändighet, proportionalitet, individers förväntningar, maskning, åtkomstkontroller, leverantörens användning, lagringstid och alternativ såsom aggregerade trattmått.

Privacy by Design and Default Policy Privacy by Design and Default Policy kräver en specifik analys av uppgiftsminimering:

[Båda] Processägaren/verksamhetsägaren MÅSTE dokumentera genomförbarheten för avidentifiering, pseudonymisering, aggregering eller icke-identifierbar behandling i REG04 innan identifierbara PII godkänns för testning, analys, rapportering eller sekundär operativ användning.

Från avsnittet ”Uppgiftsminimering och dataskyddsvänliga standardinställningar”, policyklausul 4.2.5.

Steg 4: Konfigurera dataskyddsvänliga standardinställningar före fångst i produktion

Utvecklingsteamet ska konfigurera SDK:n för att:

• inaktivera fångst av tangenttryckningar som standard
• maskera alla inmatningsfält om de inte uttryckligen har godkänts
• blockera fångst för session replay på sidor för betalning, lösenord, MFA, hälsa, HR eller känslig fritext
• ta bort token, auktoriseringshuvuden och dolda fält
• ersätta användar-ID med ett pseudonymt analys-ID där det är möjligt
• trunkera IP-adresser eller lagra dem separat med begränsad åtkomst
• tillämpa kort lagringstid för råa sessionsuppspelningar
• möjliggöra opt-out på klientorganisationsnivå där avtal kräver det
• styra åtkomst via SSO, MFA och rollbaserat godkännande
• aktivera revisionsloggar för visning, export och radering av sessionsuppspelningar

Steg 5: Uppdatera integritetsmeddelande och kunddokumentation

Privacy Notice and Transparency Policy Privacy Notice and Transparency Policy kräver att innehållet i meddelandet hämtas från REG02:

[Personuppgiftsansvarig] Processägaren/verksamhetsägaren MÅSTE inkludera PII-kategorier, kategorier av registrerade, källkategori där uppgifterna är indirekta, mottagarkategorier, lagringstidsreferens och överföringsreferens från REG02 i REG07 innan ett integritetsmeddelande lämnas in för godkännande.

Från avsnittet ”Meddelandets innehåll och transparensinformation”, policyklausul 4.2.3.

Meddelandet ska förklara produktanalys och session replay på tydligt språk: vad som fångas, varför det fångas, om det är frivilligt, vem som tar emot det, hur länge det lagras, vart det överförs och hur användare kan utöva sina rättigheter.

Steg 6: Bedöm leverantören och vidareförda avtalskrav

Före upphandling, introduktion, förnyelse eller en väsentlig funktionsändring ska REG08 användas enligt Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy:

[Alla] Processägaren/verksamhetsägaren MÅSTE identifiera varje föreslagen tredjepartsrelation som kommer att behandla, få åtkomst till, ta emot, lagra, överföra, stödja eller på annat sätt påverka PII i REG08 före upphandling, introduktion, förnyelse eller väsentlig integritetsrelaterad tredjepartsändring.

Från avsnittet ”Identifiering och klassificering av relationer”, policyklausul 4.1.2.

Leverantörsgranskningen ska omfatta dataplats, underbiträden, kryptering, åtkomstkontroller, incidentanmälan, radering, revisionsrätt, användning av kunddata, undantag för AI-träning, supportåtkomst, lagringstid, exportkontroller och incidentstöd.

Enterprise Data Protection and Privacy Policy påminner också teamen:

Avtal med personuppgiftsbiträden ska innehålla:

Från avsnittet ”Efterlevnad och tillämpning”, policyklausul 8.5.1.

SME Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME förstärker detta:

Avtal ska innehålla obligatoriska klausuler som omfattar:

Från avsnittet ”Styrningskrav”, policyklausul 5.3.

Revisionsfrågan är enkel: kan ni visa att leverantören av session replay är bunden av era dataskydds-, säkerhets-, lagrings-, raderings-, bistånds- och incidentskyldigheter?

Steg 7: Dokumentera de tekniska kontrollerna med underlag

I Zenith Blueprint, fasen Controls in Action, Step 19, ”Technological Controls I”, instruerar Clarysec team att verifiera automatiserad radering och lagringstid, granska maskning och pseudonymisering i testning och analys samt bedöma DLP-kontroller.

För session replay ska underlag bevaras såsom:

• skärmdumpar av SDK-konfiguration
• definitioner av maskningsregler
• testinspelningar som visar att känsliga fält blockeras
• konfiguration av lagringstid
• raderingsloggar
• åtkomstgranskningsposter
• leverantörens personuppgiftsbiträdesavtal och lista över underbiträden
• revisionsloggar över visning av sessionsuppspelningar
• DPIA-godkännande eller dokumenterat screeningresultat
• godkännande av integritetsmeddelande

Det är detta som gör inbyggt dataskydd från en slogan till revisionsklart underlag.

Mappning till flera regelverk för telemetristyrning

Telemetristyrning börjar ofta som en GDPR-fråga, men stannar sällan där.

GDPR Article 5 kräver laglighet, korrekthet, öppenhet, ändamålsbegränsning, uppgiftsminimering, riktighet, lagringsminimering, säkerhet och ansvarsskyldighet. Article 6 kräver rättslig grund. Article 4 klargör rollerna som personuppgiftsansvarig och personuppgiftsbiträde samt vad som utgör en personuppgiftsincident. Article 9 höjer kraven när särskilda kategorier av personuppgifter förekommer i fångat innehåll. För session replay omsätts dessa principer i tydliga meddelanden, minimerad fångst, maskerade fält, begränsad lagringstid, åtkomstkontroller, leverantörsavtal och DPIA-underlag.

NIS2 kan bli relevant för SaaS, moln, digital infrastruktur, MSP, MSSP och vissa digitala leverantörer beroende på storlek, sektor och tjänstens kritikalitet. Article 20 gör cybersäkerhetsstyrning till ett ansvar för ledningsorganet. Article 21 kräver riskhanteringsåtgärder, inklusive policyer, incidenthantering, kontinuitet, säkerhet i leveranskedjan, säker utveckling, kontrolleffektivitet, cyberhygien, kryptografi, personalsäkerhet, åtkomstkontroll och tillgångshantering.

DORA gäller många finansiella entiteter och skapar en sektorsspecifik ordning för digital operativ motståndskraft från den 17 januari 2025. Förväntningarna på IKT-riskhantering omfattar styrning, kartläggning av tillgångar och beroenden, skydd, detektering, kontinuitet, återställning, utbildning och tillsyn över tredje part. För fintech-telemetri innebär DORA-liknande tänkande att fråga om verktyg för session replay stödjer eller påverkar kritiska eller viktiga funktioner, om leverantören är en IKT-tredjepartsleverantör och om avtalen innehåller revision och incidentstöd.

NIST CSF 2.0 tillför ett praktiskt integrationslager. Funktionen GOVERN kräver förståelse för intressenter, beroenden samt rättsliga, regulatoriska, avtalsmässiga och dataskyddsrelaterade skyldigheter. Resultaten i IDENTIFY, PROTECT, DETECT, RESPOND och RECOVER mappar naturligt till telemetritillgångar, dataflöden, åtkomstkontroll, loggning, incidenttriage, begränsning och återställning.

COBIT 19-revisorer, eller ISACA-utbildade bedömare som använder styrningsprinciper, frågar normalt om telemetri stödjer organisationens mål, om riskägarskap är tydligt, om nytta balanseras mot risk, om policyer tillämpas och om övervakning visar kontrollprestanda.

Hur revisorer testar samma arbetsflöde för session replay

En dataskyddsrevisor börjar med REG02, REG04 och REG07. Revisorn väljer en aktivitet för session replay och begär ändamål, rättslig grund, kategorier av PII, kategorier av registrerade, mottagare, lagringstid, överföringar, DPIA-screening, meddelandetext och personuppgiftsbiträdesavtal. Revisorn testar om den faktiska SDK-konfigurationen motsvarar den godkända behandlingsposten. Om posten anger att inmatningsfält är maskerade begär revisorn underlag.

En ISO/IEC 27001:2022-revisor börjar med omfattning, riskbedömning, Statement of Applicability, leverantörskontroller och operativt underlag. Revisorn kan koppla telemetri till tillgångsförteckning, åtkomstkontroll, molntjänster, hantering av leverantörsrelationer, säker utveckling och incidentberedskap. Om session replay infördes genom en produktändring frågar revisorn om riskbedömningen uppdaterades och om externt tillhandahållna tjänster styrdes.

En DORA-revisor i ett fintech-sammanhang frågar om telemetri-leverantören finns i IKT-tredjepartsregistret, om tjänsten stödjer en kritisk eller viktig funktion, om avtal omfattar platser, regioner för databehandling, incidentstöd, revisionsrätt, rätt att säga upp avtalet, krav på verksamhetsberedskap och övergångsstöd.

En NIST CSF-bedömare börjar med Current Profile. Är session replay dokumenterat som ett teknikberoende och en behandlingsaktivitet? Finns ett Target Profile? Följs luckor upp i ett riskregister eller en åtgärdsplan? Uttrycks leverantörskrav i avtal? Är detekterings- och responsroller definierade om data från session replay exponeras?

En COBIT 19- eller ISACA-inriktad revisor frågar om styrningen är effektiv. Har ledningssystemet definierat ägarskap? Har intressenter rådfrågats? Accepteras risk på rätt nivå? Granskas kontrollmätetal? Är undantag synliga för ledningen? Är produktinsikten värd dataskydds- och leverantörsrisken?

Värdet med Zenith Controls är att ett arbetsflöde för session replay kan mappas över dataskydds- och säkerhetskontroller utan att skapa frikopplade underlagspaket. Samma maskningsunderlag stödjer PII-skydd, dataförlustprevention (DLP), åtkomstbegränsning och inbyggt dataskydd. Samma leverantörsgranskning stödjer molnstyrning, hantering av personuppgiftsbiträden, NIS2-säkerhet i leveranskedjan och DORA IKT-tredjepartsrisk. Samma förteckning stödjer ansvarsskyldighet enligt GDPR, ISO 27701:2025 PIMS-poster, ISO/IEC 27001:2022 tillgångshantering och NIST CSF-resultat för tillgångar.

Vanliga iakttagelser vid telemetrigranskningar

Telemetrirevisioner visar vanligtvis återkommande mönster.

För det första anger behandlingsförteckningen ”analys” men skiljer inte mellan kraschrapportering, heatmaps, session replay, supportinspelningar och AI-baserade produktinsikter. Det gör rättslig grund, meddelande och lagringstid omöjliga att validera.

För det andra finns maskning men den testas inte. Team antar att leverantören maskerar lösenord, men fritextfält, dolda fält, autofyll, anpassade komponenter eller mobila skärmar kringgår reglerna.

För det tredje är åtkomsten till sessionsuppspelningar för bred. Produkt, utveckling, support och kundframgångsteam har alla åtkomst till kontrollpanelen, men det finns ingen verksamhetsmässig motivering, periodisk granskning eller granskning av revisionsloggar.

För det fjärde är standardinställningarna för lagringstid överdrivna. Råa sessionsinspelningar sparas i månader eftersom leverantörens standard aldrig ändrades, trots att felsökningsvärdet snabbt minskar.

För det femte släpar leverantörsavtal efter användningen. Leverantören introducerades som ett produktanalysverktyg, men aktiverade senare session replay, AI-sammanfattningar, supportintegrationer eller dataexporter utan uppdaterad dataskyddsgranskning.

För det sjätte är integritetsmeddelanden generiska. De nämner analys men inte beteendereplay, enhetsidentifierare, mottagare, lagringstid eller användarval.

För det sjunde kringgår produktändringar DPIA-screening. Nya SDK-funktioner aktiveras via konfigurationsflaggor, inte via upphandling, så dataskydds- och säkerhetsteam ser aldrig ändringen.

Clarysecs lösning är inte att förbjuda telemetri. Den är att bygga en lätt men obligatorisk kontrollgrind för telemetriändringar.

Praktisk checklista för telemetristyrning

Använd denna checklista innan ni aktiverar, utökar eller förnyar produkttelemetri, mobilanalys, kraschrapportering, heatmaps eller session replay.

Koppla checklistan till stegen i Zenith Blueprint: Step 9 för tillgångsidentifiering, Step 19 för underlag avseende radering, maskning och DLP, och Step 23 för PII-skydd i praktiken. Använd därefter Zenith Controls för att mappa ISO/IEC 27002:2022-kontrollerna 5.34, 5.23, 5.19, 8.11, 5.15, 5.16, 5.8 och 8.32 så att samma underlag stödjer diskussioner om GDPR, ISO 27701:2025 PIMS, ISO/IEC 27001:2022 ISMS, NIST CSF, NIS2 och DORA.

Budskapet till styrelsen: telemetri är en förtroendekontroll

Produkttelemetri ger organisationer verkligt värde. Den hjälper team att åtgärda trasiga arbetsflöden, förbättra tillgänglighet, minska supportbelastning, upptäcka krascher, prioritera utvecklingsarbete och förstå kundresultat. Men session replay kan också bli ett övervakningslager om det är osynligt, överdrivet eller bristfälligt säkrat.

För CISO:er och regelefterlevnadsansvariga är budskapet till styrelsen enkelt: telemetri är inte bara en förmåga för produktoptimering. Den är en förtroendekontroll. Om den styrs väl förbättrar den tjänstekvaliteten samtidigt som integriteten respekteras. Om den styrs dåligt skapar den odokumenterad övervakning, okontrollerad leverantörsrisk och undvikbar exponering vid incidenter.

NIS2 förstärker ledningens ansvar för cybersäkerhetsriskhantering. DORA gör IKT-tredjepartsstyrning och resiliensstyrning centrala för finansiella entiteter. GDPR lägger ansvarsskyldighet på den personuppgiftsansvarige. ISO 27701:2025 hjälper till att operationalisera dataskyddsroller, poster, meddelanden, DPIA:er och styrning av personuppgiftsbiträden. ISO/IEC 27001:2022 tillhandahåller ISMS-motorn för risk, ägarskap, kontroller och underlag.

Clarysec för samman detta genom policyer, register, Zenith Blueprint och Zenith Controls.

Gör er telemetri revisionsklar före nästa release

Om er organisation använder produktanalys, session replay, kraschrapportering, heatmaps, mobiltelemetri eller skärminspelningar för support, börja med en fråga: kan ni visa vad som fångas, varför, enligt vilken rättslig grund, hur länge, av vem, genom vilken leverantör och med vilken maskning?

Använd Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint för att inventera telemetritillgångar, granska masknings- och raderingskontroller och bedöma leverantörsstyrning. Använd Zenith Controls: The Cross-Compliance Guide Zenith Controls för att mappa dataskydd, moln, maskning, åtkomst och leverantörskontroller mellan ramverk. Använd Clarysecs PIMS-policyer, inklusive PII Processing Inventory and Lawful Basis Policy, Privacy Risk Assessment and DPIA Policy, Privacy by Design and Default Policy, Privacy Notice and Transparency Policy och Processor, Subprocessor and Third-Party Privacy Management Policy, för att göra varje telemetriarbetsflöde spårbart.

Innan nästa SDK-reglage tas i produktion, genomför en dataskyddsgranskning av telemetristyrningen. Produktteamet får fortfarande insikt, men revisorer, kunder och användare får något mer värdefullt: underlag för förtroende.