Лични податоци во скриншоти во внатрешни бази на знаење
Внатрешните бази на знаење — Confluence, Notion, SharePoint, GitBook — содржат специфичен тип проблем со личните податоци што стандардните алатки за усогласеност го пропуштаат: лични податоци на клиентите вградени во скриншоти кои се користат за документи за процеси.
Шаблонот се повторува во илјадници тимови за поддршка и операции.
Агентот за поддршка наоѓа необично поставување на сметка. Прави скриншот на страницата на сметката на клиентот за да го документира проблемот. Скриншотот го прикажува името на клиентот во заглавјето на UI, нивната е-пошта во поставките на сметката и деталите за нивниот план.
Члинокот оди во интерната база на знаење. Сто и педесет агенти за поддршка сега можат да го видат. Дванаесет изведувачи на надворешниот помошен центар исто така можат да го видат. Членокот е корисен. Покажува како да се справи со тој граничен случај. Секој агент кој во иднина ќе наиде на тоа поставување ќе го прочита.
Три години подоцна, базата на знаење содржи 847 такви членоци. Секој содржи скриншоти на сметките на клиентите. Прикажаните клиенти не дале согласност за ова секундарно користење на нивните записи. Повеќето не знаат дека нивните податоци се таму зачувани.
Ова не е мал проблем. Расте со секој нов членок.
Изложеност согласно GDPR: Зошто ова е важно
Анализата на GDPR за скриншоти во базата на знаење е директна.
Минимизирање на податоци (член 5(1)(в)): Личните податоци мора да бидат "соодветни, релевантни и ограничени на она што е потребно". Членокот во базата на знаење за поставување на сметка не го бара реалното ime и е-поштата на клиентот. Замаглен скриншот ја исполнува истата цел. Вклучувањето на живи клиентски податоци не е потребно.
Ограничување на целта (член 5(1)(б)): Податоците собрани за една цел — услуга на клиенти — не можат да се повторно употребуваат за друга цел — интерна документација на процеси — без законска основа. Записите на сметките биле собрани за испорака на услуги, не за интерна документација. Ова се две различни цели на обработка. Користењето на истите записи за двете бара важечка законска основа што повеќето тимови не ја воспоставиле.
Контрола на пристап (член 5(1)(ж) и член 32): Соодветни технички мерки мора да ги заштитат личните податоци. Скриншоти на сметки на клиенти во алатка отворена за сите 150 агенти и изведувачи — вклучително и оние без пристап до основниот систем на сметки — создаваат претерано широк пристап.
Право на бришење (член 17): Субјектот на податоци кој бара бришење има право неговите записи да бидат отстранети "без непотребно одложување". Ако неговите податоци се јавуваат во 23 членоци на базата на знаење како вградени скриншоти, барањето бара наоѓање и ажурирање на сите 23 членоци. Тоа е тешко без систем. Нашиот водич за правото на бришење согласно GDPR ги опфаќа чекорите во детали.
Ниту едно од овие не се читања на граничен случај. Тоа се директни примени на текстот на уредбата на вообичаена практика.
Заобиколувањето на контролата на пристап
Најсериозниот проблем со усогласеноста поврзан со скриншотите во Confluence е заобиколувањето на контролата на пристап кое го создаваат.
Тимовите за поддршка користат контрола на пристап заснована на улоги (RBAC) за да ограничат кој може да ги прегледува системите на сметките на клиентите. Агентите од ниво 1 гледаат основни детали за сметките. Агентите од ниво 2 гледаат записи за наплата и технички записи. Менаџерите го гледаат целосниот профил на сметката.
Кога агентот од ниво 2 создава членок во базата на знаење со скриншот на целосната сметка на клиентот, тој скриншот станува видлив за секој корисник на алатката. Агентите од ниво 1 кои не треба да гледаат записи за наплата сега можат да ги прегледуваат. Изведувачите без системски пристап можат да ги прегледуваат. Новиот персонал при воведување може да ги прегледува.
Скриншотот ги заобиколува RBAC-контролите на системот на сметките на клиентите. Личните податоци кои RBAC требаше да ги заштити сега се отворени за секој со пристап до базата на знаење.
Ова не е теоретски ризик. Тоа е нормален резултат на работниот тек за документи. Скриншотот стои таму без датум на истекување, без евиденциски дневник и без евиденциска трага.
Практични чекори за санација
За тимови кои го откриваат овој проблем за време на ревизија за GDPR:
Ретроактивна санација:
- Идентификувајте ги сите страници на базата на знаење со прилози со слики
- Извршете откривање лични податоци во слики на секој прилог
- Прегледајте ги обележаните слики: резултатите со висока доверба одат во редот за преглед
- За секоја обележана слика: заменете со санирана верзија или ограничете го пристапот до страницата
- Евидентирајте ги акциите за санација за GDPR записите
Обемот на ретроактивна работа зависи од големината на базата на знаење. За тригодишна база на знаење во тим за поддршка со 50 лица, бројот на слики може да достигне илјадници. Пакетната обработка на слики го прави ова изводливо. Рачниот преглед на обележаните слики е клучно тесно грло.
Проспективни контроли:
- Обучете го целиот персонал за поддршка да ги санира скриншотите пред objавување во базата на знаење
- Обезбедете алатки: алатки за анотација на скриншоти кои ги замаглуваат имиња на клиенти пред залепување
- Додадете чекор за преглед: назначен рецензент ги проверува членоците пред objавување, специфично барајќи лични податоци на клиентите во слики
- Извршувајте квартално пакетно скенирање на слики на сите прилози во Confluence
Минималната одржлива контрола: Контролна листа при objавување: "Отстранете или замаглете ги сите имиња, е-пошти и ID-броеви на сметките на клиентите од скриншотите пред objавување." Ниска технологија, неавтоматизирана, но создава документирана контрола. За мали тимови, ова е почетна точка.
Видете го нашиот преглед на усогласеноста со GDPR за поширокиот правен оквир и зошто политиката без технички контроли не успева за тоа зошто пристапите само со контролни листи се распаѓаат при голем обем.
Зошто проблемот расте со текот на времето
Без систематски контроли, изложеноста на лични податоци во базата на знаење се зголемува.
Обем: Секој нов членок со скриншот на клиент ја додава вкупната изложеност. Со растот на тимот за поддршка и проширувањето на базата на знаење, акумулираните лични податоци исто така растат. Карактеристиките кои ги прават овие алатки корисни — леснотија на objавување, трајност, широк пристап — се она што го прави проблемот со личните податоци полош.
Заборавени членоци: Членоците за стари гранични случаи кои повеќе не се jавуваат остануваат достапни. Содржат лични податоци на клиентите кои оттогаш поднеле барања за бришење. Никој не проверува членок последно ажуриран во 2022 година.
Ширење меѓу тимовите: Базите на знаење честопати стануваат меѓутимски. Членок за поддршка со скриншоти на клиенти може да биде споделен со производствениот тим, инженерскиот тим или надворешните изведувачи за контекст на барање за функција или извештај за грешка. Секое споделување ja proширува публиката за личните податоци.
Заостаток за бришење: Со акумулирање на повеќе клиентски записи во базата на знаење, одговарањето на барањата за бришење станува покомплексно. Без систем, нема сигурен начин да се потврди дека е пронајдена и отстранета секоја инстанца на записите на субјектот на податоци. Тимот не може да даде веродостојна потврда за бришење.
Превенцијата на лични податоци во базата на знаење е полесна отколку нивното поправање. Контролите воспоставени сега го избегнуваат компаундниот проблем на санација. Секој членок objавен без замаглен скриншот е задача за санација одложена за иднина.