Styring af databeskyttelse ved session replay under GDPR og ISO 27701

Demoen, der gjorde produktindsigt til databeskyttelsesdokumentation

Demoskærmen lignede et gennembrud. Sarah, CISO i en hurtigt voksende SaaS-virksomhed, så produktteamet afspille en reel onboarding-session fra deres nye analyseplatform. Markøren bevægede sig gennem brugergrænsefladen, en bruger tøvede ved trin tre, klikkede tilbage to gange, åbnede en hjælpetekst og forlod derefter flowet.

Produktchefen var begejstret. Session replay ville vise præcis, hvor kunderne havde udfordringer. Heatmaps ville afsløre, hvilke felter der skabte friktion. Crashdiagnostik ville fortælle udviklingsteamet, hvilke browsere der fejlede. Mobiltelemetri ville hjælpe med at prioritere rettelser efter enhedsversion. Det lignede en guldgrube for brugeroplevelsen.

Så så Sarah, hvad værktøjet faktisk havde registreret.

Én bruger skrev ved en fejl en adgangskode i brugernavnsfeltet. En anden indsatte et nationalt ID-nummer i et fritekstfelt. En supportmedarbejder åbnede en kundekonto under en fejlfindingssession, hvilket viste finansielle data på skærmen. Crashlogfiler indeholdt e-mailadresser, IP-adresser, rutenavne, autentifikationsstatus, enhedsidentifikatorer og funktionsflag, der afslørede kundens interne arbejdsgang.

Analyseleverandøren kaldte sig databehandler. Kundekontrakten sagde, at PII fra produktionsmiljøet ikke måtte bruges til analyse uden godkendelse. Privatlivsmeddelelsen sagde kun, at virksomheden brugte analyse til at forbedre tjenesten. Den nævnte ikke session replay, adfærdsovervågning, enhedsidentifikatorer, maskering, opbevaring, modtagere eller internationale overførsler.

Produktteamet så uskadelige driftsdata. Sarah så ustrukturerede, umaskerede og ustyrede personoplysninger (PII) i en cloudplatform med bred intern adgang og uklart behandlingsgrundlag.

Det er det reelle problem med produkttelemetri og styring af databeskyttelse ved session replay. Risikoen er ikke, at telemetri findes. Risikoen er, at den behandles som tekniske restdata med lav risiko i stedet for som en styret behandlingsaktivitet, der berører behandlingsgrundlag, privatlivsmeddelelse, DPIA-screening, leverandørkontrakter, maskering, adgangsstyring, opbevaring, hændelseshåndtering og revisionsbevismateriale.

Efter ISO/IEC 27701:2025 har organisationer brug for et ledelsessystem for databeskyttelse, PIMS, der behandler databeskyttelse som en driftsmodel. Efter GDPR skal dataansvarlige kunne dokumentere overholdelse af principper som lovlighed, rimelighed, gennemsigtighed, formålsbegrænsning, dataminimering, opbevaringsbegrænsning, integritet, fortrolighed og ansvarlighed. Session replay og produkttelemetri ligger direkte i denne ansvarlighedszone, fordi de ofte overvåger, hvordan identificerbare personer agerer i en digital tjeneste.

Clarysecs tilgang er at tage telemetri ud af skyggerne og placere den i en sporbar styringskæde: fortegnelse, rolleklassificering, behandlingsgrundlag, DPIA-screening, privatlivsmeddelelse, leverandørvurdering, maskering, opbevaring, adgangsstyring, bevismateriale og løbende gennemgang. Kæden understøttes af Zenith Blueprint: En revisors 30-trins køreplan Zenith Blueprint, Clarysecs PIMS-politikker og Zenith Controls: Vejledning i kortlægning på tværs af efterlevelseskrav Zenith Controls.

Hvorfor produkttelemetri ikke bare er analyse efter GDPR

GDPR definerer personoplysninger bredt, herunder onlineidentifikatorer og oplysninger om en identificeret eller identificerbar fysisk person. Forordningen definerer også behandling bredt og omfatter indsamling, opbevaring, brug, videregivelse, sletning og destruktion. Produkttelemetri kan derfor blive behandling af personoplysninger, når den indeholder, knytter sig til eller med rimelighed kan forbindes med brugere, tenants, administratorer, medarbejdere eller kunders slutbrugere.

Almindelige datapunkter i telemetri omfatter:

• Bruger-ID’er, e-mailadresser, tenant-ID’er og konto-ID’er
• IP-adresser, enhedsidentifikatorer, browser-fingeraftryk og mobile reklame-ID’er
• Funktionsbrug, klikstier, scrolldybde, formularinteraktion og fejladfærd
• Crashdumps, rutenavne, fragmenter af API-payloads og diagnostiske logfiler
• Session replay-optagelser, DOM-snapshots, tastaturhændelser og heatmaps
• Supportmetadata, skærmbilleder, skærmoptagelser og brugerfeedback
• Ydelseshændelser knyttet til konto, rolle, geografi eller kundesegment

Databeskyttelsesproblemet bliver større, når telemetri afslører adfærd. GDPR artikel 3 kan gælde selv for SaaS-udbydere uden for EU, når de udbyder varer eller tjenester til personer i Unionen eller overvåger deres adfærd i Unionen. Session replay, heatmaps og produktanalyse er ofte adfærdsovervågning i almindelig forstand, selv når forretningsformålet er produktforbedring frem for annoncering.

GDPR artikel 6 kræver et behandlingsgrundlag for hvert behandlingsformål. Samtykke kan være relevant, hvor sporing er frivillig, indgribende eller reguleret af lokale ePrivacy-regler. Legitime interesser kan være mulige for begrænset telemetri, men kun efter vurdering af nødvendighed, proportionalitet og de registreredes rettigheder og frihedsrettigheder. Kontrakt kan understøtte telemetri, der er strengt nødvendig for at levere tjenesten, men ikke alle produktoptimeringer eller anvendelsesscenarier for replay passer naturligt under kontrakt.

Risiko ved særlige kategorier er også relevant. GDPR artikel 9 begrænser behandling af oplysninger, der afslører helbredsoplysninger, biometriske, politiske, religiøse eller andre følsomme kategorier. Mange SaaS-leverandører antager, at de ikke indsamler disse data, men opdager senere, at kunder indsætter dem i supportformularer, workflowfelter, noter, HR-registre, beskrivelser af juridiske sager, medicinske krav eller skærmbilleder, der registreres af replay-værktøjer.

Clarysecs Enterprise Databeskyttelses- og privatlivspolitik Data Protection and Privacy Policy gør behandlingsgrundlag og dataminimering eksplicit:

Al behandling skal være baseret på et gyldigt retligt grundlag, f.eks. samtykke, kontrakt eller retlig forpligtelse.

Fra afsnittet ‘Krav til implementering af politikken’, politikklausul 6.1.1.

Kun data, der er nødvendige for et specifikt, legitimt forretningsformål, må indsamles og behandles.

Fra afsnittet ‘Krav til implementering af politikken’, politikklausul 6.2.1.

For mindre teams kræver Data Protection and Privacy Policy-sme Data Protection and Privacy Policy - SME disciplin i fortegnelsen:

Koordinatoren for databeskyttelse skal vedligeholde et register over alle behandlingsaktiviteter vedrørende personoplysninger, herunder datakategorier, formål, behandlingsgrundlag og opbevaringsperioder.

Fra afsnittet ‘Styringskrav’, politikklausul 5.2.1.

Den giver også produkt- og engineeringteams en klar baseline for databeskyttelse gennem design og standardindstillinger:

Databeskyttelse gennem design og standardindstillinger skal håndhæves i alle nye systemer og tjenester.

Fra afsnittet ‘Styringskrav’, politikklausul 5.3.1.

Styringskorrektionen er enkel: Spørg ikke, om telemetri er “analyse”. Spørg, om det er en behandlingsaktivitet, der involverer PII, adfærdsovervågning, profilering, leverandøradgang, opbevaring og sikkerhedskontroller.

Begynd med rolleklarhed efter ISO 27701:2025

Databeskyttelsesstyring efter ISO/IEC 27701:2025 fungerer bedst, når organisationer først definerer deres rolle. Handler I som dataansvarlig, der beslutter, hvorfor session replay bruges, og hvilke data der registreres? Er I databehandler, der registrerer telemetri på vegne af en kunde efter dokumenteret instruks? Er I begge dele afhængigt af funktion og kundekonfiguration?

Clarysecs PIMS-politiksæt bruger rolletags til at gøre dette operationelt. “Begge” gælder, uanset om organisationen handler som dataansvarlig eller databehandler. “Dataansvarlig” gælder, hvor organisationen fastlægger formål og midler. “Databehandler” gælder, hvor behandlingen udføres efter dokumenteret instruks.

En SaaS-udbyder kan være dataansvarlig for telemetri, der bruges til at forbedre eget produkt, identificere UX-friktion eller prioritere produkt-roadmap. Den samme udbyder kan være databehandler for telemetri, der registreres i et kundekontrolleret arbejdsområde, hvor kunden fastlægger formålet. I sjældne tilfælde kan fælles dataansvar opstå, hvor begge parter i fællesskab fastlægger formål og midler. I andre kæder kan udbyderen være underdatabehandler, der håndterer telemetri for en anden databehandler.

Enterprise PII Processing Inventory and Lawful Basis Policy PII Processing Inventory and Lawful Basis Policy gør den første kontrolport konkret:

[Begge] Procesejeren / virksomhedsejeren SKAL oprette en REG02-post i fortegnelsen over behandlingsaktiviteter, før en ny behandlingsaktivitet vedrørende PII påbegyndes.

Fra afsnittet ‘Baseline for fortegnelse over behandlingsaktiviteter’, politikklausul 4.1.1.

For produkttelemetri bør REG02 ikke indeholde en vag “analyse”-række. Den bør adskille formål og dataflows.

ISO/IEC 27001:2022 understøtter dette PIMS-arbejde ved at give organisationen struktur for kontekst, krav fra interessenter, omfang, ledelse, roller, risikovurdering, behandlingsplanlægning, operationel styring og eksternt leverede tjenester. ISMS’et spørger, hvilke aktiver, risici, ejere, kontroller og hvilket bevismateriale der findes. PIMS’et spørger, hvilke PII der behandles, hvorfor, under hvilken rolle, med hvilke rettigheder, sikkerhedsforanstaltninger og meddelelser.

Sammen forhindrer de det klassiske databeskyttelseshul, hvor produktteams aktiverer sporing hurtigere, end styringen kan klassificere den.

DPIA-udløsere: når produktindsigt bliver behandling med høj risiko

Ikke alle telemetrihændelser kræver en fuld DPIA. Men session replay og adfærdsanalyse kræver ofte DPIA-screening, fordi de kan indebære systematisk overvågning, profilering, omfattende behandling, følsomt indhold, sårbare brugere, innovativ teknologi eller væsentligt ændret behandling.

Privacy Risk Assessment and DPIA Policy Privacy Risk Assessment and DPIA Policy er eksplicit for dataansvarlige:

[Dataansvarlig] Procesejeren / virksomhedsejeren SKAL henvise behandling, der omfatter omfattende systematisk overvågning, profilering, automatiserede afgørelser, særlige kategorier af PII, oplysninger om straffedomme og lovovertrædelser, sårbare registrerede, innovativ teknologi eller væsentligt ændret behandling, til den databeskyttelsesansvarlige / PIMS-ansvarlige i REG04, før behandlingen påbegyndes.

Fra afsnittet ‘DPIA-udløsere og fastlæggelse af krav’, politikklausul 4.2.2.

En DPIA-screening af session replay bør stille praktiske spørgsmål:

• Registrerer replay formularinput, sideindhold, chattekst, uploadede dokumenter eller fejl-payloads?
• Sker maskering, før data forlader browseren, eller først efter indtagelse?
• Kan værktøjet registrere adgangskoder, tokens, hemmeligheder, engangskoder eller betalingsfelter?
• Er sessioner knyttet til navngivne brugere, konti, IP-adresser eller enhedsidentifikatorer?
• Kan medarbejdere søge i replays efter bruger, kunde, segment, fejl, URL eller adfærd?
• Bruger leverandøren dataene til analyse, AI-træning, benchmarking eller produktforbedring?
• Er der internationale overførsler?
• Hvilken opbevaringsperiode er konfigureret, og kan sletning håndhæves pr. tenant eller bruger?
• Kan kunder deaktivere replay, konfigurere maskering eller anmode om sletning?
• Er medarbejdere, administratorer og kunders slutbrugere dækket af meddelelser?
• Er der risiko for registrering af børns data, helbredsdata, finansielle data eller HR-data?

Enterprise Databeskyttelses- og privatlivspolitik understøtter tærsklen for høj risiko:

Trusselsmodellering og konsekvensanalyser vedrørende databeskyttelse (DPIA’er) er obligatoriske for behandlingssystemer med høj risiko.

Fra afsnittet ‘Krav til implementering af politikken’, politikklausul 6.3.4.

En vigtig Clarysec-erfaring fra revisioner er, at risikoen ved session replay ikke kun er et databeskyttelsesspørgsmål. Det er også et spørgsmål om sikkerhedsarkitektur. Hvis DOM-snapshots registrerer bearer tokens, interne ID’er, skjulte felter eller følsomme kundearbejdsgange, har organisationen skabt et nyt højværdi-datalager uden for sin normale perimeter for logning, DLP og gennemgang af adgangsrettigheder.

Gør replay-værktøjet til et revisionsbart aktiv

Den hurtigste måde at reducere telemetririsiko på er at stoppe med at behandle værktøjer som usynlig produktinfrastruktur. I Zenith Blueprint, fasen Risikostyring, trin 9, “Identifying Assets, Threats, and Vulnerabilities,” instruerer Clarysec organisationer i at registrere aktiver og dokumentere ejer, lokation og klassificering. Blueprintet bemærker specifikt, at personoplysningsaktiver bør markeres for GDPR-relevans, og at kritiske serviceaktiver bør markeres for mulig NIS2-anvendelighed.

Blueprintet beskriver et informationsaktiv som alt af værdi, der kan blive skadet af en sikkerhedshændelse, herunder information, software, cloudtjenester, tjenester/processer og tredjepartstjenester. For telemetristyring bliver hver analyseplatform, replay-leverandør, SDK, event-pipeline, data lake, dashboard, eksport og repository for supportoptagelser et revisionsbart aktiv.

Dette kobler databeskyttelsesstyring til ISMS-bevismateriale. Produkt-, databeskyttelses-, engineering- og revisionsteams kan pege på samme registrering i stedet for at vedligeholde separate fortællinger.

Brug Zenith Controls som rygrad for kortlægning på tværs af efterlevelseskrav

Clarysec bruger Zenith Controls som vejledning i kortlægning på tværs af efterlevelseskrav, ikke som erstatning for officielle frameworks. For telemetri og session replay er de centrale temaer i ISO/IEC 27002:2022 databeskyttelse og beskyttelse af PII, styring af cloudtjenester, leverandørrelationer, datamaskering, aktivfortegnelse, klassificering, adgangsstyring og ændringsstyring.

I Zenith Controls er ISO/IEC 27002:2022 kontrol 5.34, Privacy and protection of PII, ankeret. Det praktiske fundament er datakendskab:

Fundamentet for denne kontrol er datakendskab. Organisationen skal vide, hvilke PII den indsamler, hvor de befinder sig, hvorfor de behandles, og hvem der kan få adgang til dem.

Fra Zenith Blueprint, fasen Controls in Action, trin 23, kontrol 5.34, Privacy and Protection of Personally Identifiable Information.

Zenith Controls kortlægger 5.34 til understøttende ISO/IEC 27002:2022-kontroller såsom 5.9 inventory of information and other associated assets, 8.11 data masking, 5.23 information security for use of cloud services, 5.12 classification of information, 5.14 information transfer, 5.15 access control, 5.16 identity management, 5.19 information security in supplier relationships, 5.8 information security in project management og 8.32 change management.

For datamaskering identificerer Zenith Controls ISO/IEC 27002:2022 kontrol 8.11 som forebyggende og fokuseret på fortrolighed. Den kobler også maskering til 8.3 information access restriction, 8.10 information deletion, 8.12 data leakage prevention, 8.24 use of cryptography og 8.33 test information. Det er vigtigt, fordi maskering i session replay ikke må være kosmetisk. Den skal designes, testes og dokumenteres.

Data Masking and Pseudonymization Policy-sme Data Masking and Pseudonymization Policy - SME giver en enkel regel, der også gælder for produktanalyse:

Levende personoplysninger må ikke anvendes i test, eksterne værktøjer eller analyse, medmindre det er formelt godkendt.

Fra afsnittet ‘Roller og ansvar’, politikklausul 4.4.1.

En praktisk Clarysec-arbejdsgang til godkendelse af session replay

Forestil dig, at produktteamet vil aktivere replay for alle fejlede checkout-sessioner i en fintech-app. Forretningscasen er reel: afbrudt checkout påvirker omsætning og kundetilfredshed. Styringsspørgsmålet er, om denne indsigt kan indsamles lovligt, proportionalt og sikkert.

Trin 1: Opret REG02, før SDK’et sættes i drift

Brug REG02 efter PII Processing Inventory and Lawful Basis Policy. Registrer formål, datakategorier, brugerkategorier, kilde, modtagere, opbevaring, overførsler, systemejer, behandlingsgrundlag og rolle.

Skriv ikke “analyse”. Skriv “session replay til fejlfinding af fejlede checkout-forløb og forbedring af konvertering”. Angiv konkrete felter, herunder bruger-ID, tenant-ID, IP-adresse, enheds-ID, klikhændelser, sideruter, DOM-snapshots, maskerede formularfelter, fejlkoder og status for betalingsflow.

Trin 2: Fastlæg behandlingsgrundlag

For grundlæggende crashdiagnostik og aggregerede performancemetrikker kan legitime interesser være forsvarlige, hvis organisationen dokumenterer nødvendighed, proportionalitet, sikkerhedsforanstaltninger og brugernes forventninger. For fuld session replay, især på autentificerede skærme, kan samtykke være klarere, hvor lokale regler eller graden af indgriben kræver det.

En hybrid tilgang er ofte mere praktisk: brug legitime interesser til begrænset, ikke-indgribende, maskeret telemetri, og kræv eksplicit opt-in eller aktivering på tenant-niveau for session replay. Uanset svaret skal det dokumenteres og afspejles i meddelelser, kontrakter og konfiguration.

Trin 3: Screen for DPIA-udløsere i REG04

Replay af fejlede checkout-forløb kan involvere finansiel adfærd, autentifikation, betalingsskærme og systematisk overvågning. Procesejeren henviser aktiviteten til den databeskyttelsesansvarlige. Screeningen vurderer nødvendighed, proportionalitet, individuelle forventninger, maskering, adgangskontroller, leverandørens brug, opbevaring og alternativer såsom aggregerede funnel-metrikker.

Privacy by Design and Default Policy Privacy by Design and Default Policy kræver en specifik analyse af dataminimering:

[Begge] Procesejeren / virksomhedsejeren SKAL dokumentere gennemførligheden af afidentifikation, pseudonymisering, aggregering eller ikke-identificerbar behandling i REG04, før identificerbar PII godkendes til test, analyse, rapportering eller sekundær driftsmæssig anvendelse.

Fra afsnittet ‘Dataminimering og databeskyttelse som standard gennem design’, politikklausul 4.2.5.

Trin 4: Konfigurer databeskyttende standardindstillinger før registrering i produktion

Engineering bør konfigurere SDK’et til at:

• Deaktivere registrering af tastetryk som standard
• Maskere alle inputfelter, medmindre de udtrykkeligt er godkendt
• Blokere replay-registrering på betalings-, adgangskode-, MFA-, helbreds-, HR- eller følsomme fritekstsider
• Fjerne tokens, autorisationsheaders og skjulte felter
• Erstatte bruger-ID med et pseudonymt analyse-ID, hvor det er muligt
• Afkorte IP-adresser eller opbevare dem særskilt med begrænset adgang
• Anvende kort opbevaringstid for rå replay
• Aktivere opt-out på tenant-niveau, hvor det kræves kontraktuelt
• Rute adgang gennem SSO, MFA og rollebaseret godkendelse
• Aktivere revisionslogfiler for visning, eksport og sletning af replay

Trin 5: Opdater privatlivsmeddelelse og kundedokumentation

Privacy Notice and Transparency Policy Privacy Notice and Transparency Policy kræver, at meddelelsesindhold hentes fra REG02:

[Dataansvarlig] Procesejeren / virksomhedsejeren SKAL inkludere PII-kategorier, kategorier af registrerede, kildekategori hvor indirekte, modtagerkategorier, opbevaringsreference og overførselsreference fra REG02 i REG07, før en privatlivsmeddelelse indsendes til godkendelse.

Fra afsnittet ‘Meddelelsesindhold og gennemsigtighedsoplysninger’, politikklausul 4.2.3.

Meddelelsen bør forklare produktanalyse og replay i klart sprog: hvad der registreres, hvorfor det registreres, om det er frivilligt, hvem der modtager det, hvor længe det opbevares, hvor det overføres, og hvordan brugere kan udøve deres rettigheder.

Trin 6: Vurder leverandøren og viderefør kontraktkrav

Før indkøb, onboarding, fornyelse eller en væsentlig funktionsændring skal REG08 anvendes efter Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy:

[Alle] Procesejeren / virksomhedsejeren SKAL identificere hver foreslået tredjepartsrelation, der vil behandle, tilgå, modtage, opbevare, transmittere, understøtte eller på anden måde påvirke PII i REG08 før indkøb, onboarding, fornyelse eller væsentlig ændring vedrørende tredjepartsdatabeskyttelse.

Fra afsnittet ‘Identifikation og klassificering af relationen’, politikklausul 4.1.2.

Leverandørgennemgang bør dække datalokation, underdatabehandlere, kryptering, adgangskontroller, underretning ved brud, sletning, revisionsrettigheder, brug af kundedata, undtagelser for AI-træning, supportadgang, opbevaring, eksportkontroller og samarbejde ved hændelser.

Enterprise Databeskyttelses- og privatlivspolitik minder også teams om:

Kontrakter med databehandlere skal indeholde:

Fra afsnittet ‘Håndhævelse og efterlevelse’, politikklausul 8.5.1.

SME Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME understreger, at:

Kontrakter skal indeholde obligatoriske klausuler, der dækker:

Fra afsnittet ‘Styringskrav’, politikklausul 5.3.

Revisionsspørgsmålet er ligetil: Kan I dokumentere, at replay-leverandøren er bundet af jeres databeskyttelses-, sikkerheds-, opbevarings-, sletnings-, bistands- og hændelsesforpligtelser?

Trin 7: Dokumentér de tekniske kontroller

I Zenith Blueprint, fasen Controls in Action, trin 19, “Technological Controls I,” instruerer Clarysec teams i at verificere automatiseret sletning og opbevaring, gennemgå maskering og pseudonymisering i test og analyse samt vurdere DLP-kontroller.

For replay skal der opbevares bevismateriale såsom:

• Skærmbilleder af SDK-konfiguration
• Definitioner af maskeringsregler
• Testoptagelser, der viser, at følsomme felter er blokeret
• Opbevaringskonfiguration
• Sletningslogfiler
• Registreringer af gennemgang af adgangsrettigheder
• Leverandørens databehandleraftale og liste over underdatabehandlere
• Revisionslogfiler for visning af replay
• DPIA-godkendelse eller dokumenteret screeningsresultat
• Godkendelse af privatlivsmeddelelse

Det er sådan, databeskyttelse gennem design omsættes fra slogan til revisionsklart bevismateriale.

Kortlægning af telemetristyring på tværs af efterlevelseskrav

Telemetristyring begynder ofte som et GDPR-spørgsmål, men forbliver sjældent kun det.

GDPR artikel 5 kræver lovlighed, rimelighed, gennemsigtighed, formålsbegrænsning, dataminimering, rigtighed, opbevaringsbegrænsning, sikkerhed og ansvarlighed. Artikel 6 kræver behandlingsgrundlag. Artikel 4 præciserer rollerne som dataansvarlig, databehandler og ved brud. Artikel 9 hæver kravene, når særlige kategorier af personoplysninger optræder i registreret indhold. For session replay omsættes disse principper til klare meddelelser, minimeret registrering, maskerede felter, begrænset opbevaring, adgangskontroller, leverandørkontrakter og DPIA-bevismateriale.

NIS2 kan blive relevant for SaaS, cloud, digital infrastruktur, MSP, MSSP og visse digitale udbydere afhængigt af størrelse, sektor og tjenestens kritikalitet. Artikel 20 gør cybersikkerhedsstyring til et ansvar for ledelsesorganet. Artikel 21 kræver risikostyringsforanstaltninger, herunder politikker, hændelseshåndtering, kontinuitet, sikkerhed i forsyningskæden, sikker udvikling, kontroleffektivitet, cyberhygiejne, kryptografi, personalesikkerhed, adgangsstyring og styring af aktiver.

DORA gælder for mange finansielle enheder og etablerer fra 17. januar 2025 et sektorspecifikt regelsæt for digital operationel robusthed. Forventningerne til styring af IKT-risiko omfatter governance, kortlægning af aktiver og afhængigheder, beskyttelse, detektion, kontinuitet, genopretning, træning og tilsyn med tredjeparter. For fintech-telemetri spørger en DORA-orienteret tilgang, om replay-værktøjer understøtter eller påvirker kritiske eller vigtige funktioner, om leverandøren er en IKT-tredjepartsudbyder, og om kontrakter omfatter revisions- og hændelsesbistand.

NIST CSF 2.0 tilføjer et praktisk integrationslag. Funktionen GOVERN kræver forståelse af interessenter, afhængigheder samt juridiske, regulatoriske, kontraktlige og databeskyttelsesrelaterede forpligtelser. Resultaterne i IDENTIFY, PROTECT, DETECT, RESPOND og RECOVER kan naturligt kortlægges til telemetriaktiver, dataflows, adgangsstyring, logning, hændelsestriage, inddæmning og genopretning.

COBIT 19-revisorer eller ISACA-uddannede assessorer, der anvender governance-principper, vil normalt spørge, om telemetri understøtter virksomhedens mål, om risikoejerskab er klart, om gevinster afbalanceres med risiko, om politikker håndhæves, og om overvågning dokumenterer kontroludførelse.

Hvordan revisorer tester den samme replay-arbejdsgang

En databeskyttelsesrevisor begynder med REG02, REG04 og REG07. Revisoren udvælger en replay-aktivitet og anmoder om formål, behandlingsgrundlag, kategorier af PII, kategorier af registrerede, modtagere, opbevaring, overførsler, DPIA-screening, meddelelsestekst og databehandleraftaler. Revisoren tester, om den faktiske SDK-konfiguration stemmer overens med den godkendte behandlingsregistrering. Hvis registreringen siger, at inputfelter er maskeret, anmoder revisoren om bevismateriale.

En ISO/IEC 27001:2022-revisor begynder med omfang, risikovurdering, anvendelighedserklæring (SoA), leverandørkontroller og operationelt bevismateriale. Revisoren kan knytte telemetri til aktivfortegnelse, adgangsstyring, cloudtjenester, styring af leverandørrelationer, sikker udvikling og hændelsesberedskab. Hvis replay blev indført gennem en produktændring, spørger revisoren, om risikovurderingen blev opdateret, og om eksternt leverede tjenester blev styret.

En DORA-revisor i en fintech-kontekst spørger, om telemetri-leverandøren er opført i IKT-tredjepartsregisteret, om tjenesten understøtter en kritisk eller vigtig funktion, og om kontrakter omfatter lokationer, databehandlingsregioner, hændelsesbistand, revisionsrettigheder, opsigelsesrettigheder, krav til forretningsberedskab og overgangsbistand.

En NIST CSF-assessor begynder med den aktuelle profil. Er session replay dokumenteret som en teknologiafhængighed og behandlingsaktivitet? Findes der en måltilstand? Spores mangler i et risikoregister eller en handlingsplan? Er leverandørkrav udtrykt i kontrakter? Er roller for detektion og respons defineret, hvis replay-data eksponeres?

En COBIT 19- eller ISACA-orienteret revisor spørger, om governance er effektiv. Har ledelsessystemet defineret ejerskab? Er interessenter hørt? Accepteres risiko på rette niveau? Gennemgås kontrolmetrikker? Er undtagelser synlige for ledelsen? Er produktindsigten databeskyttelses- og leverandørrisikoen værd?

Værdien af Zenith Controls er, at én replay-arbejdsgang kan kortlægges på tværs af databeskyttelses- og sikkerhedskontroller uden at skabe frakoblede bevispakker. Det samme maskeringsbevis understøtter PII-beskyttelse, datatabsforebyggelse, adgangsbegrænsning og databeskyttelse gennem design. Den samme leverandørgennemgang understøtter cloud-governance, databehandlerstyring, NIS2-sikkerhed i forsyningskæden og DORA IKT-tredjepartsrisiko. Den samme fortegnelse understøtter GDPR-ansvarlighed, ISO 27701:2025 PIMS-registreringer, ISO/IEC 27001:2022-styring af aktiver og NIST CSF-resultater for aktiver.

Almindelige konstateringer i gennemgange af telemetri

Revisioner af telemetri afdækker normalt gentagne mønstre.

For det første siger fortegnelsen over behandlingsaktiviteter “analyse”, men skelner ikke mellem crashrapportering, heatmaps, replay, supportoptagelser og AI-baseret produktindsigt. Det gør det umuligt at validere behandlingsgrundlag, meddelelse og opbevaring.

For det andet findes maskering, men den testes ikke. Teams antager, at leverandøren maskerer adgangskoder, men fritekstfelter, skjulte felter, autocomplete, specialbyggede komponenter eller mobile skærme omgår reglerne.

For det tredje er replay-adgangen for bred. Produkt, engineering, support og customer success har alle dashboardadgang, men der findes ingen forretningsmæssig begrundelse, periodisk gennemgang eller gennemgang af revisionslogfiler.

For det fjerde er standardindstillinger for opbevaring for omfattende. Rå sessionsoptagelser opbevares i måneder, fordi leverandørens standard aldrig blev ændret, selv om værdien for fejlfinding hurtigt falder.

For det femte halter leverandørkontrakter efter brugen. Leverandøren blev onboardet som et produktanalyseværktøj, men aktiverede senere replay, AI-resuméer, supportintegrationer eller dataeksporter uden opdateret databeskyttelsesgennemgang.

For det sjette er privatlivsmeddelelser generiske. De nævner analyse, men ikke adfærdsbaseret replay, enhedsidentifikatorer, modtagere, opbevaring eller brugervalg.

For det syvende omgår produktændringer DPIA-screening. Nye SDK-funktioner aktiveres via konfigurationstoggles og ikke gennem indkøb, så databeskyttelses- og sikkerhedsteams ser aldrig ændringen.

Clarysec-løsningen er ikke at forbyde telemetri. Den er at etablere en let, men obligatorisk kontrolport for ændringer i telemetri.

Praktisk tjekliste for telemetristyring

Brug denne tjekliste, før produkttelemetri, mobilanalyse, crashrapportering, heatmaps eller session replay aktiveres, udvides eller fornyes.

Knyt tjeklisten til trinnene i Zenith Blueprint: trin 9 for identifikation af aktiver, trin 19 for bevismateriale vedrørende sletning, maskering og DLP, og trin 23 for PII-beskyttelse i praksis. Brug derefter Zenith Controls til at kortlægge ISO/IEC 27002:2022-kontrollerne 5.34, 5.23, 5.19, 8.11, 5.15, 5.16, 5.8 og 8.32, så det samme bevismateriale understøtter dialoger om GDPR, ISO 27701:2025 PIMS, ISO/IEC 27001:2022 ISMS, NIST CSF, NIS2 og DORA.

Budskabet til bestyrelsen: telemetri er en tillidskontrol

Produkttelemetri giver organisationer reel værdi. Den hjælper teams med at rette ødelagte arbejdsgange, forbedre tilgængelighed, reducere supportbelastning, opdage crashes, prioritere engineeringarbejde og forstå kundernes resultater. Men session replay kan også blive et overvågningslag, hvis det er usynligt, overdrevent eller dårligt sikret.

For CISO’er og compliance-ansvarlige er budskabet til bestyrelsen enkelt: Telemetri er ikke kun en produktoptimeringskapacitet. Det er en tillidskontrol. Når den styres godt, forbedrer den tjenestekvaliteten med respekt for databeskyttelse. Når den styres dårligt, skaber den udokumenteret overvågning, ukontrolleret leverandørrisiko og undgåelig eksponering ved brud.

NIS2 understreger ledelsens ansvarlighed for cybersikkerhedsrisikostyring. DORA gør IKT-tredjeparter og robusthedsstyring centrale for finansielle enheder. GDPR placerer ansvarligheden hos den dataansvarlige. ISO 27701:2025 hjælper med at operationalisere databeskyttelsesroller, registreringer, meddelelser, DPIA’er og databehandlerstyring. ISO/IEC 27001:2022 leverer ISMS-motoren for risiko, ejerskab, kontroller og bevismateriale.

Clarysec samler disse gennem politikker, registre, Zenith Blueprint og Zenith Controls.

Gør jeres telemetri revisionsklar før næste release

Hvis jeres organisation bruger produktanalyse, session replay, crashrapportering, heatmaps, mobiltelemetri eller supportskærmoptagelser, skal I begynde med ét spørgsmål: Kan I dokumentere, hvad der registreres, hvorfor, på hvilket behandlingsgrundlag, hvor længe, af hvem, gennem hvilken leverandør og med hvilken maskering?

Brug Zenith Blueprint: En revisors 30-trins køreplan Zenith Blueprint til at registrere telemetriaktiver, gennemgå kontroller for maskering og sletning og vurdere leverandørstyring. Brug Zenith Controls: Vejledning i kortlægning på tværs af efterlevelseskrav Zenith Controls til at kortlægge databeskyttelses-, cloud-, maskerings-, adgangs- og leverandørkontroller på tværs af frameworks. Brug Clarysecs PIMS-politikker, herunder PII Processing Inventory and Lawful Basis Policy, Privacy Risk Assessment and DPIA Policy, Privacy by Design and Default Policy, Privacy Notice and Transparency Policy og Processor, Subprocessor and Third-Party Privacy Management Policy, så hver telemetriarbejdsgang bliver sporbar.

Før næste SDK-toggle sættes i drift, skal I gennemføre en gennemgang af databeskyttelsesstyringen for telemetri. Produktteamet får stadig indsigt, men jeres revisorer, kunder og brugere får noget mere værdifuldt: dokumentation for tillid.