Řízení ochrany soukromí u nahrávání a přehrávání relací podle GDPR a ISO 27701

Demo, které proměnilo produktový vhled v důkazní problém ochrany soukromí

Demonstrační obrazovka vypadala jako průlom. Sarah, CISO rychle rostoucí SaaS společnosti, sledovala, jak produktový tým v nové analytické platformě přehrává skutečnou onboardingovou relaci. Kurzor se pohyboval po rozhraní, uživatel se ve třetím kroku zastavil, dvakrát klikl zpět, otevřel nápovědu a poté proces opustil.

Produktový manažer byl nadšený. Nahrávání a přehrávání relací mělo přesně ukázat, kde zákazníci narážejí. Heatmapy měly odhalit, která pole způsobují tření. Diagnostika pádů měla vývojářům ukázat, ve kterých prohlížečích dochází k selhání. Mobilní telemetrie měla pomoci určovat priority oprav podle verze zařízení. Vypadalo to jako zlatý důl pro zlepšení uživatelské zkušenosti.

Pak Sarah uviděla, co nástroj skutečně zachytil.

Jeden uživatel omylem napsal heslo do pole pro uživatelské jméno. Jiný vložil národní identifikační číslo do pole pro volný text. Pracovník podpory při řešení problému otevřel zákaznický účet, čímž se na obrazovce zobrazily finanční údaje. Logy pádů obsahovaly e-mailové adresy, IP adresy, názvy tras, stav autentizace, identifikátory zařízení a feature flags, které odhalovaly interní pracovní postup zákazníka.

Dodavatel analytiky sám sebe označoval za zpracovatele. Zákaznická smlouva uváděla, že produkční PII nesmí být používána pro analytiku bez schválení. Oznámení o ochraně osobních údajů pouze říkalo, že společnost používá analytiku ke zlepšování služby. Nezmiňovalo nahrávání a přehrávání relací, monitorování chování, identifikátory zařízení, maskování, uchovávání, příjemce ani mezinárodní předávání.

Produktový tým viděl neškodná provozní data. Sarah viděla nestrukturované, nemaskované a neřízené osobně identifikovatelné údaje (PII) v cloudové platformě s širokým interním přístupem a nejasným právním základem.

To je skutečný problém řízení ochrany soukromí u produktové telemetrie a nahrávání a přehrávání relací. Rizikem není samotná existence telemetrie. Rizikem je, že je považována za technický odpad s nízkým rizikem, nikoli za řízenou činnost zpracování, která se dotýká právního základu, oznámení o ochraně osobních údajů, předběžného posouzení nutnosti DPIA, dodavatelských smluv, maskování, řízení přístupu, uchovávání, reakce na incidenty a auditních důkazů.

Podle ISO/IEC 27701:2025 organizace potřebují systém řízení informací o soukromí (Privacy Information Management System, PIMS), který pojímá ochranu soukromí jako provozní model. Podle GDPR musí správci prokázat soulad se zásadami, jako jsou zákonnost, korektnost, transparentnost, účelové omezení, minimalizace údajů, omezení uložení, integrita, důvěrnost a odpovědnost. Nahrávání a přehrávání relací a produktová telemetrie spadají přímo do této oblasti odpovědnosti, protože často monitorují, jak se identifikovatelné osoby chovají uvnitř digitální služby.

Přístup Clarysec spočívá v tom, že se telemetrie vyvede ze stínu a začlení do dohledatelného řetězce řízení: evidence, klasifikace role, právní základ, předběžné posouzení nutnosti DPIA, oznámení o ochraně osobních údajů, posouzení dodavatele, maskování, uchovávání, řízení přístupu, důkazy a průběžný přezkum. Tento řetězec podporují Zenith Blueprint: 30krokový plán auditora Zenith Blueprint, politiky PIMS společnosti Clarysec a Zenith Controls: průvodce souladem napříč rámci Zenith Controls.

Proč produktová telemetrie není podle GDPR jen analytika

GDPR definuje osobní údaje široce, včetně online identifikátorů a informací vztahujících se k identifikované nebo identifikovatelné fyzické osobě. Široce definuje také zpracování, které zahrnuje shromažďování, ukládání, používání, zpřístupnění, výmaz a zničení. Produktová telemetrie se proto může stát zpracováním osobních údajů, pokud obsahuje údaje o uživatelích, tenantech, administrátorech, zaměstnancích nebo koncových uživatelích zákazníků, je s nimi propojena nebo s nimi může být rozumně spojena.

Mezi běžné datové body telemetrie patří:

• ID uživatelů, e-mailové adresy, ID tenantů a ID účtů
• IP adresy, identifikátory zařízení, fingerprinty prohlížeče a mobilní reklamní ID
• Používání funkcí, klikací cesty, hloubka scrollování, interakce s formuláři a chování při chybách
• Výpisy pádů, názvy tras, fragmenty API payloadů a diagnostické logy
• Záznamy pro přehrávání relací, snapshoty DOM, události stisku kláves a heatmapy
• Metadata podpory, snímky obrazovky, záznamy obrazovky a uživatelská zpětná vazba
• Výkonnostní události propojené s účtem, rolí, geografickou oblastí nebo zákaznickým segmentem

Problém ochrany soukromí se prohlubuje, když telemetrie odhaluje chování. GDPR Article 3 se může vztahovat i na poskytovatele SaaS mimo EU, pokud nabízejí zboží nebo služby osobám v Unii nebo monitorují jejich chování v Unii. Nahrávání a přehrávání relací, heatmapy a produktová analytika jsou v běžném jazyce často monitorováním chování, i když je obchodním účelem zlepšení produktu, nikoli reklama.

GDPR Article 6 vyžaduje právní základ pro každý účel zpracování. Souhlas může být vhodný tam, kde je sledování volitelné, invazivní nebo se řídí místními pravidly ePrivacy. Oprávněný zájem může být u omezené telemetrie možný, ale pouze po posouzení nezbytnosti, přiměřenosti a práv a svobod fyzických osob. Smlouva může podpořit telemetrii, která je nezbytně nutná k poskytování služby, ale ne každá optimalizace produktu nebo scénář přehrávání relace se pod smluvní právní základ bezpečně vejde.

Důležité je také riziko zvláštních kategorií osobních údajů. GDPR Article 9 omezuje zpracování údajů vypovídajících o zdraví, biometrických údajů, politických nebo náboženských názorech a dalších citlivých kategoriích. Mnozí poskytovatelé SaaS předpokládají, že takové údaje neshromažďují, a následně zjistí, že je zákazníci vkládají do formulářů podpory, polí pracovních postupů, poznámek, HR záznamů, popisů právních věcí, zdravotních nároků nebo snímků obrazovky zachycených nástroji pro přehrávání relací.

Podniková Politika ochrany údajů a soukromí Politika ochrany údajů a soukromí společnosti Clarysec výslovně stanoví právní základ a minimalizaci:

Veškeré zpracování musí být založeno na platném právním důvodu (např. souhlas, smlouva, právní povinnost).

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.1.1.

Shromažďovat a zpracovávat lze pouze údaje nezbytné pro konkrétní legitimní obchodní účel.

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.2.1.

Pro menší týmy vyžaduje Politika ochrany údajů a soukromí pro SME Politika ochrany údajů a soukromí pro SME důslednou evidenci:

Koordinátor ochrany soukromí musí vést registr všech činností zpracování osobních údajů, včetně kategorií údajů, účelu, právního základu a dob uchovávání.

Ze sekce „Požadavky na řízení“, ustanovení politiky 5.2.1.

Produktovým a vývojovým týmům zároveň poskytuje jasný základ podle zásady ochrany soukromí již od návrhu:

Ochrana soukromí již od návrhu a ve výchozím nastavení musí být vynucována ve všech nových systémech a službách.

Ze sekce „Požadavky na řízení“, ustanovení politiky 5.3.1.

Nápravný krok v oblasti řízení je jednoduchý: neptejte se, zda je telemetrie „analytika“. Ptejte se, zda jde o činnost zpracování zahrnující PII, monitorování chování, profilování, přístup dodavatele, uchovávání a bezpečnostní opatření.

Začněte jasným vymezením rolí podle ISO 27701:2025

Řízení ochrany soukromí podle ISO/IEC 27701:2025 funguje nejlépe, když organizace nejprve definuje svou roli. Vystupujete jako správce PII, který rozhoduje, proč se nahrávání a přehrávání relací používá a jaké údaje se zachycují? Jste zpracovatel, který zachycuje telemetrii jménem zákazníka na základě dokumentovaných pokynů? Nebo jste obojí, podle konkrétní funkce a zákaznické konfigurace?

Sada politik PIMS společnosti Clarysec používá značky rolí, aby bylo toto rozlišení provozně použitelné. „Obě role“ platí bez ohledu na to, zda organizace vystupuje jako správce nebo zpracovatel. „Správce“ platí tam, kde organizace určuje účely a prostředky. „Zpracovatel“ platí tam, kde je zpracování prováděno podle dokumentovaných pokynů.

Poskytovatel SaaS může být správcem pro telemetrii používanou ke zlepšení vlastního produktu, odhalení tření v UX nebo stanovení priorit roadmapy. Tentýž poskytovatel může být zpracovatelem pro telemetrii zachycenou v zákazníkem řízeném pracovním prostoru, kde účel určuje zákazník. Ve vzácných případech může vzniknout společné správcovství, pokud obě strany společně určují účely a prostředky. V jiných řetězcích může poskytovatel vystupovat jako dílčí zpracovatel zpracovávající telemetrii pro jiného zpracovatele.

Podniková Politika evidence zpracování PII a právního základu Politika evidence zpracování PII a právního základu konkretizuje první kontrolní bod:

[Obě role] Vlastník procesu / vlastník organizace MUSÍ vytvořit záznam v evidenci činností zpracování REG02 před zahájením jakékoli nové činnosti zpracování PII.

Ze sekce „Výchozí evidence činností zpracování“, ustanovení politiky 4.1.1.

U produktové telemetrie by REG02 neměl obsahovat vágní řádek „analytika“. Měl by oddělit účely a toky dat.

ISO/IEC 27001:2022 podporuje tuto práci v PIMS tím, že organizaci poskytuje strukturu pro kontext, požadavky zainteresovaných stran, rozsah, vedení, role, posouzení rizik, plánování ošetření rizik, provozní řízení a externě poskytované služby. ISMS se ptá, jaká jsou aktiva, rizika, vlastníci, opatření a důkazy. PIMS se ptá, jaké PII se zpracovává, proč, v jaké roli, s jakými právy, ochrannými opatřeními a oznámeními.

Společně brání klasické mezeře v ochraně soukromí, kdy produktové týmy zapínají sledování rychleji, než je řízení dokáže klasifikovat.

Spouštěcí podmínky DPIA: kdy se produktový vhled stává vysoce rizikovým zpracováním

Ne každá telemetrická událost vyžaduje úplné posouzení vlivu na ochranu osobních údajů (DPIA). Nahrávání a přehrávání relací a behaviorální analytika však často vyžadují předběžné posouzení nutnosti DPIA, protože mohou zahrnovat systematické monitorování, profilování, rozsáhlé zpracování, citlivý obsah, zranitelné uživatele, inovativní technologii nebo významnou změnu zpracování.

Politika posouzení rizik pro soukromí a DPIA Politika posouzení rizik pro soukromí a DPIA je pro správce výslovná:

[Správce] Vlastník procesu / vlastník organizace MUSÍ před zahájením zpracování předat zpracování zahrnující rozsáhlé systematické monitorování, profilování, automatizované rozhodování, zvláštní kategorie PII, údaje o odsouzeních za trestné činy nebo přestupcích, zranitelné subjekty PII, inovativní technologii nebo významně změněné zpracování vedoucímu oblasti ochrany soukromí / manažerovi PIMS v REG04.

Ze sekce „Spouštěcí podmínky DPIA a určení požadavku“, ustanovení politiky 4.2.2.

Předběžné posouzení nutnosti DPIA pro nahrávání a přehrávání relací by mělo klást praktické otázky:

• Zachycuje přehrávání vstupy do formulářů, obsah stránek, text chatu, nahrané dokumenty nebo chybové payloady?
• Probíhá maskování před tím, než data opustí prohlížeč, nebo až po příjmu dat?
• Může nástroj zachytit hesla, tokeny, tajemství, jednorázové kódy nebo platební pole?
• Jsou relace propojené s pojmenovanými uživateli, účty, IP adresami nebo identifikátory zařízení?
• Mohou zaměstnanci vyhledávat záznamy podle uživatele, zákazníka, segmentu, chyby, URL nebo chování?
• Používá dodavatel data pro analytiku, trénování AI, benchmarking nebo zlepšování produktu?
• Dochází k mezinárodnímu předávání?
• Jaká doba uchovávání je nastavena a lze výmaz vynutit podle tenantu nebo uživatele?
• Mohou zákazníci přehrávání vypnout, konfigurovat maskování nebo požádat o výmaz?
• Jsou oznámeními pokryti zaměstnanci, administrátoři a koncoví uživatelé zákazníků?
• Existuje riziko zachycení osobních údajů dětí, zdravotních údajů, finančních údajů nebo HR údajů?

Podniková Politika ochrany údajů a soukromí posiluje práh vysokého rizika:

Modelování hrozeb a posouzení vlivu na ochranu osobních údajů (DPIA) jsou povinné pro systémy zpracování s vysokým rizikem.

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.3.4.

Důležitým poznatkem Clarysec z auditů je, že riziko nahrávání a přehrávání relací není jen otázkou ochrany soukromí. Je to také otázka bezpečnostní architektury. Pokud snapshoty DOM zachycují bearer tokeny, interní ID, skrytá pole nebo citlivé zákaznické pracovní postupy, organizace vytvořila nové vysoce hodnotné datové úložiště mimo svůj běžný perimetr protokolování, DLP a přezkumu přístupových oprávnění.

Udělejte z nástroje pro přehrávání auditovatelné aktivum

Nejrychlejší způsob, jak snížit riziko telemetrie, je přestat s nástroji zacházet jako s neviditelnou produktovou infrastrukturou. V Zenith Blueprint, ve fázi řízení rizik, kroku 9 „Identifikace aktiv, hrozeb a zranitelností“, Clarysec organizacím ukládá evidovat aktiva a zaznamenávat vlastníka, umístění a klasifikaci. Výslovně uvádí, že aktiva obsahující osobní údaje mají být označena z hlediska relevance pro GDPR a aktiva kritických služeb mají být označena z hlediska možné použitelnosti NIS2.

Blueprint vymezuje informační aktivum jako cokoli hodnotného, co by mohlo být poškozeno bezpečnostním incidentem, včetně informací, softwaru, cloudových služeb, služeb/procesů a služeb třetích stran. Pro řízení telemetrie se každá analytická platforma, dodavatel přehrávání, SDK, pipeline událostí, datové jezero, řídicí panel, export a repozitář záznamů podpory stává auditovatelným aktivem.

Tím se řízení ochrany soukromí propojuje s důkazy ISMS. Produktové, privacy, vývojové a auditní týmy mohou odkazovat na stejný záznam místo toho, aby udržovaly oddělené narativy.

Použijte Zenith Controls jako páteř souladu napříč rámci

Clarysec používá Zenith Controls jako průvodce souladem napříč rámci, nikoli jako náhradu oficiálních rámců. U telemetrie a nahrávání a přehrávání relací jsou ústředními tématy ISO/IEC 27002:2022 ochrana soukromí a ochrana PII, správa cloudových služeb, vztahy s dodavateli, maskování dat, evidence aktiv, klasifikace, řízení přístupu a řízení změn.

V Zenith Controls je kotvou opatření ISO/IEC 27002:2022 5.34, ochrana soukromí a ochrana PII. Jeho praktickým základem je znalost dat:

Základem tohoto opatření je znalost dat. Organizace musí vědět, jaké PII shromažďuje, kde se nacházejí, proč jsou zpracovávána a kdo k nim má přístup.

Ze Zenith Blueprint, fáze „Opatření v praxi“, krok 23, opatření 5.34, ochrana soukromí a ochrana osobně identifikovatelných údajů.

Zenith Controls mapuje 5.34 na podpůrná opatření ISO/IEC 27002:2022, jako jsou 5.9 evidence informací a dalších souvisejících aktiv, 8.11 maskování dat, 5.23 bezpečnost informací při používání cloudových služeb, 5.12 klasifikace informací, 5.14 přenos informací, 5.15 řízení přístupu, 5.16 správa identit, 5.19 bezpečnost informací ve vztazích s dodavateli, 5.8 bezpečnost informací v projektovém řízení a 8.32 řízení změn.

U maskování dat Zenith Controls identifikuje opatření ISO/IEC 27002:2022 8.11 jako preventivní a zaměřené na důvěrnost. Maskování také propojuje s 8.3 omezením přístupu k informacím, 8.10 výmazem informací, 8.12 prevencí úniku dat, 8.24 používáním kryptografie a 8.33 testovacími informacemi. To je důležité, protože maskování při nahrávání a přehrávání relací nemůže být pouze kosmetické. Musí být navrženo, otestováno a doloženo důkazy.

Politika maskování dat a pseudonymizace pro SME Politika maskování dat a pseudonymizace pro SME poskytuje jednoduché pravidlo, které platí i pro produktovou analytiku:

Produkční osobní údaje se nesmí používat při testování, v externích nástrojích ani v analytice, pokud to nebylo formálně schváleno.

Ze sekce „Role a odpovědnosti“, ustanovení politiky 4.4.1.

Praktický pracovní postup Clarysec pro schválení nahrávání a přehrávání relací

Představte si, že produktový tým chce ve fintech aplikaci zapnout přehrávání všech neúspěšných checkout relací. Obchodní důvod je reálný: opuštěný checkout ovlivňuje tržby i spokojenost zákazníků. Otázkou řízení je, zda lze tento vhled získat zákonně, přiměřeně a bezpečně.

Krok 1: Vytvořte REG02 před uvedením SDK do produkce

Použijte REG02 podle Politiky evidence zpracování PII a právního základu. Zaznamenejte účel, kategorie údajů, kategorie uživatelů, zdroj, příjemce, uchovávání, předávání, vlastníka systému, právní základ a roli.

Nepište „analytika“. Napište „nahrávání a přehrávání relací pro řešení neúspěšného checkoutu a zlepšení konverze“. Uveďte konkrétní pole, včetně ID uživatele, ID tenantu, IP adresy, ID zařízení, událostí kliknutí, tras stránek, snapshotů DOM, maskovaných formulářových polí, chybových kódů a stavu platebního toku.

Krok 2: Určete právní základ

U základní diagnostiky pádů a agregovaných výkonnostních metrik může být oprávněný zájem obhajitelný, pokud organizace dokumentuje nezbytnost, přiměřenost, ochranná opatření a očekávání uživatelů. U úplného nahrávání a přehrávání relací, zejména na autentizovaných obrazovkách, může být jasnější souhlas, pokud jej vyžadují místní pravidla nebo míra zásahu do soukromí.

Hybridní přístup je často praktičtější: použít oprávněný zájem pro omezenou, neinvazivní a maskovanou telemetrii a pro nahrávání a přehrávání relací vyžadovat výslovné přihlášení nebo zapnutí na úrovni tenantu. Ať je výsledek jakýkoli, musí být dokumentován a promítnut do oznámení, smluv a konfigurace.

Krok 3: Proveďte předběžné posouzení spouštěcích podmínek DPIA v REG04

Přehrávání neúspěšného checkoutu může zahrnovat finanční chování, autentizaci, platební obrazovky a systematické monitorování. Vlastník procesu předá činnost vedoucímu oblasti ochrany soukromí. Předběžné posouzení hodnotí nezbytnost, přiměřenost, očekávání jednotlivců, maskování, řízení přístupu, použití dodavatelem, uchovávání a alternativy, jako jsou agregované metriky funnelu.

Politika ochrany soukromí již od návrhu a ve výchozím nastavení Politika ochrany soukromí již od návrhu a ve výchozím nastavení vyžaduje konkrétní analýzu minimalizace:

[Obě role] Vlastník procesu / vlastník organizace MUSÍ v REG04 dokumentovat proveditelnost deidentifikace, pseudonymizace, agregace nebo neidentifikovatelného zpracování před schválením identifikovatelných PII pro testování, analytiku, reporting nebo sekundární provozní použití.

Ze sekce „Minimalizace údajů a návrh s ochranou soukromí ve výchozím nastavení“, ustanovení politiky 4.2.5.

Krok 4: Nakonfigurujte výchozí nastavení ochrany soukromí před produkčním zachytáváním

Vývoj by měl SDK nakonfigurovat tak, aby:

• Ve výchozím nastavení zakázal zachytávání stisků kláves
• Maskoval všechna vstupní pole, pokud nebyla výslovně schválena
• Blokoval zachytávání přehrávání na platebních stránkách, stránkách s hesly, MFA, zdravotními údaji, HR údaji nebo citlivými poli pro volný text
• Odstraňoval tokeny, autorizační hlavičky a skrytá pole
• Tam, kde je to proveditelné, nahrazoval ID uživatele pseudonymním analytickým ID
• Zkracoval IP adresy nebo je ukládal odděleně s omezeným přístupem
• Uplatňoval krátkou dobu uchovávání surových záznamů přehrávání
• Umožňoval opt-out na úrovni tenantu tam, kde to vyžaduje smlouva
• Směroval přístup přes SSO, MFA a schvalování podle rolí
• Zapnul auditní logy pro prohlížení, export a výmaz záznamů přehrávání

Krok 5: Aktualizujte oznámení o ochraně osobních údajů a zákaznickou dokumentaci

Politika oznámení o ochraně osobních údajů a transparentnosti Politika oznámení o ochraně osobních údajů a transparentnosti vyžaduje, aby obsah oznámení vycházel z REG02:

[Správce] Vlastník procesu / vlastník organizace MUSÍ před předložením oznámení o ochraně osobních údajů ke schválení zahrnout do REG07 kategorie PII, kategorie subjektů PII, kategorii zdroje v případě nepřímého získání, kategorie příjemců, odkaz na uchovávání a odkaz na předávání z REG02.

Ze sekce „Obsah oznámení a transparentní informace“, ustanovení politiky 4.2.3.

Oznámení by mělo srozumitelně vysvětlit produktovou analytiku a přehrávání: co se zachycuje, proč se to zachycuje, zda je to volitelné, kdo údaje přijímá, jak dlouho se uchovávají, kam jsou předávány a jak mohou uživatelé uplatnit svá práva.

Krok 6: Posuďte dodavatele a přenesené smluvní povinnosti

Před pořizováním, onboardingem, obnovením smlouvy nebo významnou změnou funkce použijte REG08 podle Politiky správy zpracovatelů, dílčích zpracovatelů a třetích stran v oblasti ochrany soukromí Politika správy zpracovatelů, dílčích zpracovatelů a třetích stran v oblasti ochrany soukromí:

[Všichni] Vlastník procesu / vlastník organizace MUSÍ před pořizováním, onboardingem, obnovením smlouvy nebo významnou změnou vztahu se třetí stranou z hlediska ochrany soukromí identifikovat v REG08 každý navrhovaný vztah se třetí stranou, která bude zpracovávat, zpřístupňovat, přijímat, ukládat, přenášet, podporovat nebo jinak ovlivňovat PII.

Ze sekce „Identifikace a klasifikace vztahu“, ustanovení politiky 4.1.2.

Přezkum dodavatele by měl pokrýt umístění dat, dílčí zpracovatele, šifrování, řízení přístupu, oznamování porušení zabezpečení, výmaz, práva na audit, používání zákaznických dat, vyloučení trénování AI, přístup pracovníků podpory, uchovávání, kontroly exportu a spolupráci při incidentech.

Podniková Politika ochrany údajů a soukromí týmům také připomíná:

Smlouvy se zpracovateli musí obsahovat:

Ze sekce „Vynucování a dodržování“, ustanovení politiky 8.5.1.

SME Bezpečnostní politika třetích stran a dodavatelů pro SME Bezpečnostní politika třetích stran a dodavatelů pro SME posiluje, že:

Smlouvy musí obsahovat povinná ustanovení zahrnující:

Ze sekce „Požadavky na řízení“, ustanovení politiky 5.3.

Auditní otázka je přímočará: můžete prokázat, že dodavatel přehrávání je vázán vašimi povinnostmi v oblasti ochrany soukromí, bezpečnosti, uchovávání, výmazu, součinnosti a incidentů?

Krok 7: Doložte technická opatření

V Zenith Blueprint, ve fázi „Opatření v praxi“, kroku 19 „Technická opatření I“, Clarysec týmům ukládá ověřit automatizovaný výmaz a uchovávání, přezkoumat maskování a pseudonymizaci při testování a analytice a posoudit opatření DLP.

U přehrávání uchovávejte například tyto důkazy:

• Snímky obrazovky konfigurace SDK
• Definice pravidel maskování
• Testovací záznamy prokazující zablokování citlivých polí
• Konfigurace uchovávání
• Logy výmazu
• Záznamy o přezkumu přístupových oprávnění
• DPA s dodavatelem a seznam dílčích zpracovatelů
• Auditní logy prohlížení záznamů přehrávání
• Schválení DPIA nebo dokumentovaný výsledek předběžného posouzení
• Schválení oznámení o ochraně osobních údajů

To je postup, který mění ochranu soukromí již od návrhu z hesla na důkazy připravené pro audit.

Mapování souladu napříč rámci pro řízení telemetrie

Řízení telemetrie často začíná jako otázka GDPR, ale málokdy u něj zůstane.

GDPR Article 5 vyžaduje zákonnost, korektnost, transparentnost, účelové omezení, minimalizaci údajů, přesnost, omezení uložení, bezpečnost a odpovědnost. Article 6 vyžaduje právní základ. Article 4 vyjasňuje role správce, zpracovatele a porušení zabezpečení. Article 9 zvyšuje požadavky tam, kde se v zachyceném obsahu objeví zvláštní kategorie osobních údajů. U nahrávání a přehrávání relací se tyto zásady promítají do jasných oznámení, minimalizovaného zachytávání, maskovaných polí, omezeného uchovávání, řízení přístupu, dodavatelských smluv a důkazů k DPIA.

NIS2 může být relevantní pro SaaS, cloud, digitální infrastrukturu, MSP, MSSP a určité digitální poskytovatele v závislosti na velikosti, odvětví a kritičnosti služby. Article 20 činí řízení kybernetické bezpečnosti odpovědností vedoucího orgánu. Article 21 vyžaduje opatření řízení rizik, včetně politik, zvládání incidentů, kontinuity, zabezpečení dodavatelského řetězce, bezpečného vývoje, účinnosti kontrol, kybernetické hygieny, kryptografie, bezpečnosti lidských zdrojů, řízení přístupu a správy aktiv.

DORA se vztahuje na mnoho finančních subjektů a od 17. ledna 2025 vytváří odvětvový režim digitální provozní odolnosti. Její očekávání v oblasti řízení rizik v oblasti ICT zahrnují řízení a správu, mapování aktiv a závislostí, ochranu, detekci, kontinuitu, obnovu, školení a dohled nad třetími stranami. U fintech telemetrie uvažování ve stylu DORA zkoumá, zda nástroje pro přehrávání podporují nebo ovlivňují kritické či důležité funkce, zda je dodavatel poskytovatelem služeb IKT z řad třetích stran a zda smlouvy obsahují auditní součinnost a součinnost při incidentech.

NIST CSF 2.0 přidává praktickou integrační vrstvu. Jeho funkce GOVERN vyžaduje porozumění zainteresovaným stranám, závislostem a právním, regulačním, smluvním a povinnostem v oblasti ochrany soukromí. Výstupy IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER se přirozeně mapují na telemetrická aktiva, toky dat, řízení přístupu, protokolování, triáž incidentů, zamezení šíření a obnovu.

Auditoři COBIT 19 nebo hodnotitelé vyškolení podle ISACA s využitím principů řízení se obvykle ptají, zda telemetrie podporuje podnikové cíle, zda je jasné vlastnictví rizik, zda jsou přínosy vyváženy riziky, zda jsou politiky uplatňovány a zda monitorování prokazuje výkonnost kontrol.

Jak auditoři testují stejný pracovní postup přehrávání

Auditor ochrany soukromí začíná u REG02, REG04 a REG07. Vybere činnost přehrávání a požádá o účel, právní základ, kategorie PII, kategorie subjektů PII, příjemce, uchovávání, předávání, předběžné posouzení nutnosti DPIA, text oznámení a smlouvy se zpracovateli. Testuje, zda skutečná konfigurace SDK odpovídá schválenému záznamu o zpracování. Pokud záznam říká, že vstupní pole jsou maskována, požádá o důkazy.

Auditor ISO/IEC 27001:2022 začíná rozsahem, posouzením rizik, Prohlášením o použitelnosti, kontrolami dodavatelů a provozními důkazy. Telemetrii může propojit s evidencí aktiv, řízením přístupu, cloudovými službami, řízením vztahů s dodavateli, bezpečným vývojem a připraveností na incidenty. Pokud bylo přehrávání zavedeno prostřednictvím produktové změny, ptá se, zda bylo aktualizováno posouzení rizik a zda byly řízeny externě poskytované služby.

Auditor DORA ve fintech kontextu se ptá, zda je dodavatel telemetrie uveden v registru třetích stran v oblasti ICT, zda služba podporuje kritickou nebo důležitou funkci, zda smlouvy obsahují lokality, regiony zpracování dat, součinnost při incidentech, práva na audit, práva při ukončení, požadavky na kontinuitu činností a součinnost při přechodu.

Hodnotitel NIST CSF začíná aktuálním profilem. Je nahrávání a přehrávání relací dokumentováno jako technologická závislost a činnost zpracování dat? Existuje cílový stav? Jsou mezery sledovány v registru rizik nebo v plánu opatření a milníků? Jsou požadavky na dodavatele vyjádřeny ve smlouvách? Jsou definovány role pro detekci a reakci v případě expozice dat přehrávání?

Auditor COBIT 19 nebo auditor ve stylu ISACA se ptá, zda je řízení účinné. Definoval systém řízení vlastnictví? Byly konzultovány zainteresované strany? Je riziko akceptováno na správné úrovni? Jsou přezkoumávány metriky opatření? Jsou výjimky viditelné pro vedení? Stojí produktový vhled za riziko pro soukromí a dodavatelské riziko?

Hodnota Zenith Controls spočívá v tom, že jeden pracovní postup přehrávání lze mapovat napříč opatřeními ochrany soukromí a bezpečnosti, aniž by vznikaly oddělené balíčky důkazů. Stejné důkazy o maskování podporují ochranu PII, prevenci úniku dat, omezení přístupu a ochranu soukromí již od návrhu. Stejný přezkum dodavatele podporuje správu cloudu, řízení zpracovatelů, zabezpečení dodavatelského řetězce podle NIS2 a řízení rizik třetích stran v oblasti ICT podle DORA. Stejná evidence podporuje odpovědnost podle GDPR, záznamy PIMS podle ISO 27701:2025, správu aktiv podle ISO/IEC 27001:2022 a výstupy aktiv podle NIST CSF.

Běžná zjištění při přezkumech telemetrie

Audity telemetrie obvykle odhalují opakující se vzorce.

Zaprvé, evidence činností zpracování uvádí „analytika“, ale nerozlišuje hlášení pádů, heatmapy, přehrávání, záznamy podpory a produktové vhledy založené na AI. Tím se stává nemožným ověřit právní základ, oznámení a uchovávání.

Zadruhé, maskování existuje, ale není testováno. Týmy předpokládají, že dodavatel maskuje hesla, ale pole pro volný text, skrytá pole, autocomplete, vlastní komponenty nebo mobilní obrazovky pravidla obcházejí.

Zatřetí, přístup k přehrávání je příliš široký. Produkt, vývoj, podpora i customer success mají přístup k řídicímu panelu, ale neexistuje obchodní odůvodnění, pravidelný přezkum ani přezkum auditních logů.

Začtvrté, výchozí nastavení uchovávání jsou nadměrná. Surové záznamy relací se uchovávají měsíce, protože výchozí nastavení dodavatele nebylo nikdy změněno, přestože hodnota pro řešení problémů rychle klesá.

Zapáté, dodavatelské smlouvy zaostávají za skutečným použitím. Dodavatel byl onboardován jako nástroj produktové analytiky, ale později zapnul přehrávání, AI souhrny, integrace podpory nebo exporty dat bez aktualizovaného přezkumu ochrany soukromí.

Zašesté, oznámení o ochraně osobních údajů jsou obecná. Zmiňují analytiku, ale nikoli behaviorální přehrávání, identifikátory zařízení, příjemce, uchovávání nebo volby uživatelů.

Zasedmé, produktové změny obcházejí předběžné posouzení nutnosti DPIA. Nové funkce SDK se zapínají konfiguračními přepínači, nikoli přes pořizování, takže týmy ochrany soukromí a bezpečnosti změnu nikdy neuvidí.

Řešením Clarysec není telemetrii zakázat. Řešením je vytvořit lehký, ale povinný kontrolní bod pro změny telemetrie.

Praktický kontrolní seznam pro řízení telemetrie

Použijte tento kontrolní seznam před zapnutím, rozšířením nebo obnovením produktové telemetrie, mobilní analytiky, hlášení pádů, heatmap nebo nahrávání a přehrávání relací.

Propojte kontrolní seznam s kroky Zenith Blueprint: krok 9 pro identifikaci aktiv, krok 19 pro důkazy k výmazu, maskování a DLP a krok 23 pro ochranu PII v praxi. Poté použijte Zenith Controls k mapování opatření ISO/IEC 27002:2022 5.34, 5.23, 5.19, 8.11, 5.15, 5.16, 5.8 a 8.32 tak, aby stejné důkazy podporovaly diskuse o GDPR, ISO 27701:2025 PIMS, ISO/IEC 27001:2022 ISMS, NIST CSF, NIS2 a DORA.

Sdělení pro správní radu: telemetrie je opatření důvěry

Produktová telemetrie přináší organizacím skutečnou hodnotu. Pomáhá týmům opravovat nefunkční pracovní postupy, zlepšovat přístupnost, snižovat zátěž podpory, detekovat pády, určovat priority vývojových prací a chápat zákaznické výsledky. Nahrávání a přehrávání relací se však může stát také vrstvou dohledu, pokud je neviditelné, nadměrné nebo nedostatečně zabezpečené.

Pro CISO a vedoucí zajištění souladu je sdělení pro správní radu jednoduché: telemetrie není jen schopnost optimalizace produktu. Je to opatření důvěry. Pokud je dobře řízena, zlepšuje kvalitu služby a zároveň respektuje soukromí. Pokud je řízena špatně, vytváří nedokumentované monitorování, neřízené dodavatelské riziko a zbytečnou expozici vůči porušení zabezpečení.

NIS2 posiluje odpovědnost vedení za řízení rizik kybernetické bezpečnosti. DORA staví řízení třetích stran v oblasti ICT a řízení odolnosti do centra pozornosti finančních subjektů. GDPR ukládá odpovědnost správci. ISO 27701:2025 pomáhá operacionalizovat role v ochraně soukromí, záznamy, oznámení, DPIA a správu zpracovatelů. ISO/IEC 27001:2022 poskytuje mechanismus ISMS pro rizika, vlastnictví, opatření a důkazy.

Clarysec tyto prvky propojuje prostřednictvím politik, registrů, Zenith Blueprint a Zenith Controls.

Připravte telemetrii na audit před dalším vydáním

Pokud vaše organizace používá produktovou analytiku, nahrávání a přehrávání relací, hlášení pádů, heatmapy, mobilní telemetrii nebo záznamy obrazovky podpory, začněte jednou otázkou: můžete prokázat, co se zachycuje, proč, na jakém právním základě, jak dlouho, kým, prostřednictvím jakého dodavatele a s jakým maskováním?

Použijte Zenith Blueprint: 30krokový plán auditora Zenith Blueprint k evidenci telemetrických aktiv, přezkumu maskování a kontrol výmazu a posouzení správy dodavatelů. Použijte Zenith Controls: průvodce souladem napříč rámci Zenith Controls k mapování opatření ochrany soukromí, cloudu, maskování, přístupu a dodavatelů napříč rámci. Použijte politiky PIMS společnosti Clarysec, včetně Politiky evidence zpracování PII a právního základu, Politiky posouzení rizik pro soukromí a DPIA, Politiky ochrany soukromí již od návrhu a ve výchozím nastavení, Politiky oznámení o ochraně osobních údajů a transparentnosti a Politiky správy zpracovatelů, dílčích zpracovatelů a třetích stran v oblasti ochrany soukromí, aby byl každý telemetrický pracovní postup dohledatelný.

Než se další přepínač SDK dostane do produkce, proveďte přezkum řízení ochrany soukromí u telemetrie. Váš produktový tým bude mít stále potřebný vhled, ale vaši auditoři, zákazníci a uživatelé získají něco hodnotnějšího: důkazy důvěry.