Зошто Excel е Вашиот Фајл Тип со Највисок Ризик
Excel фајловите се еден од најголемите GDPR ризици во повеќето бизниси. Медицинските записи можат да носат поосетливи податоци по ред. Но табелите брзо акумулираат лични податоци — и тимовите за усогласеност честопати ги пропуштаат.
Три работи ги прават Excel фајловите тешки за управување.
Обем: Еден XLSX фајл може да содржи 50.000 редови и 100 колони. Тоа се пет милиони ќелии. Ниеден рачен преглед не може да ги провери сите.
Решеткест распоред: Текстот тече во една насока. Excel ги шири податоците низ редови и колони. Личните податоци можат да се скријат насекаде во таа мрежа.
Мешана содржина: Платежни скали, шифри на одделенија и работни оцени се наоѓаат во ист фајл со ЕМБГ-а и е-пошта адреси. Бришењето на сé го прави фајлот бескорисен.
Долго задржување: Листите на вработени и записите за клиенти остануваат во Excel со години. GDPR Член 5(1)(е) вели дека податоците мора да се чуваат "не подолго отколку е потребно". Фајловите кои "можеби ќе бидат корисни" честопати остануваат далеку подолго.
Зошто Стандардните Текстуални Скенирања Не Успеваат на Табели
Алатките за текстуална анализа беа изградени за документи. Тие не успеваат на табели на неколку вообичаени начини.
Проблемот на ЕМБГ-како-Број
Excel ги зачувува матичните броеви без цртички (1234567890123) како обични броеви, а не текст. Скенер изграден за наоѓање ###-##-#### ќе ги пропушти. Добра алатка мора да знае дека 13-цифрен број во колона наречена "ЕМБГ" е матичен број.
Проблемот на Датум-како-Број
Excel ги зачувува датумите како серијски броеви. 6 февруари 2024 е зачуван како 45329. CSV извозот ќе покаже "45329" во колона "Датум на раѓање". Скенерот мора да го конвертира тој број во вистински датум пред да може да ја означи вредноста.
Проблемот на Делумен ЕМБГ
Некои системи прикажуваат само последните четири цифри на ЕМБГ (*--1234). Целосниот број се наоѓа во заклучена колона. Делумната вредност сепак мора да биде анонимизирана — дури и ако не изгледа како целосен ЕМБГ.
Проблемот на Формула-Личен-Податок
Некои ќелии градат лични податоци од други ќелии. Ќелија со =CONCATENATE(B2," ",C2) прикажува цело ime. Ако ги исчистите колоните B и C, тоа цело ime е сеуште видливо во ќелијата со формула. Алатка која чита само зачувани вредности — не врски на формули — ќе остави лични податоци на место.
Проблемот на Повеќе Листови
Голема работна книга може да има пет листови: Листа на клиенти, Нарачки, Барања за поддршка, Наплата и Аналитика. Имињата на клиенти се появуваат во сите пет. "Иван Петров" во еден лист мора да стане ист токен — "PERSON_0047" — во секој друг лист. Два различни токени ги кршат врските помеѓу записите.
Заглавија на Колони Како Сигнал
Најдоброто подобрување во откривањето на лични податоци во табели е анализата на заглавија на колони.
Колона наречена "ЕМБГ" кажува на алатката дека сите вредности во таа колона се матични броеви. Ова функционира дури и ако вредностите се делумни, чудно форматирани или зачувани како броеви.
| Заглавие на колона | Што сигнализира |
|---|---|
| ЕМБГ / Матичен број / Даночен ID | Третирај 13-цифрени броеви како ЕМБГ |
| Е-пошта / Електронска пошта | Означи дури и делумни шеми за е-пошта |
| Телефон / Мобилен / Клетка | Прифати кој-бидело телефонски формат |
| Датум на раѓање / Роденден | Конвертирај серијски броеви во датуми |
| Ime / Презиме / Цело ime | Намали ги барањата за откривање на иминa |
| Адреса / Улица / Град / Поштенски | Комбинирај блиски полиња за локација |
| ID на пациент / MRN / Број на запис | Применувај шеми за здравствен ID |
Контекстот на колоните не го заменува скенирањето на содржина. Тој се додава на него. Колона наречена "ЕМБГ" со 100 вредности: скенирањето на содржина фаќа 99 добро форматирани. Контекстот на колоните го фаќа оној кој изгледа чудно.
Задржете ја Структурата, Отстранете ги Имињата
Целта во повеќето случаи на Excel GDPR не е да го уништите фајлот. Тоа е да ги отстраните личните податоци додека ги задржувате деловите кои го прават фајлот корисен.
За фајл со 15.000 редови записи на вработени, службеник за усогласеност треба:
Отстранете:
- Имиња на вработени → токени PERSON_XXXX
- ЕМБГ-а → REDACTED
- Е-пошта адреси → REDACTED
- Телефонски броеви → REDACTED
- Домашни адреси → REDACTED
Задржете:
- Шифри на одделенија
- Работни функции (само општи улоги)
- Платежни скали (широки категории)
- Оцени за перформанси (групни податоци)
- Датуми на почеток (за статистика на стаж)
- Шифри на менаџери (ако се псевдонимизирани)
Алатка која ја знае разликата помеѓу "податоци кои именуваат луѓе" и "податоци кои ги опишуваат работите" ви дава фајл кој сеуште функционира за HR анализа — и ги исполнува правилата за минимизирање на GDPR податоци.
Реален Случај: Пренос на HR Податоци при Спојување и Превземање
Обединувачка компанија добива записи за вработени од целна фирма: XLSX со 15.000 редови и 40 колони. Фајлот мора да се испрати до надворешна HR фирма за планирање на бенефиции. GDPR вели дека само податоците потребни за таа задача можат да се споделат.
Пред обработка: 40 колони со цели имиња, ЕМБГ-а, е-пошти, домашни адреси, контакти во итни случаи и банкарски податоци.
По обработка со контекст на колони:
- 12 колони директно ги идентификуваат луѓето (имиња, ЕМБГ-а, е-пошти, телефон, адреси, банкарски податоци): заменети со конзистентни токени
- 3 колони индиректно ги идентификуваат луѓето (ID на персоналот, шифра на менаџер, шифра на работа): заменети со псевдонимни токени кои се совпаѓаат во фајлот
- 25 колони се агрегатни податоци (платежна скала, одделение, стаж, степен): оставени непроменети
Времетраење: 8 минути за 600.000 ќелии
Излез: Ист XLSX распоред, 40 колони, 15 анонимизирани, 25 непроменети
Ревизиски дневник: Запис на ниво на ќелија за секоја акција со тип на ентитет, резултат на доверба и употребен сигнал на колона
HR фирмата добива целосен сет на податоци за своја работа — без имиња или ID-а. Записот за усогласеност добива доказ дека само правилните податоци биле споделени.
Овој предизвик не е уникатен за Excel. Секој формат на фајл не успева на свој начин. Видете како фрагментацијата на формати влијае на откривање на лични податоци за преглед низ типовите на фајлови.
Три GDPR Правила на Член 5, Еден Процес
Структурираната анонимизација на табели ги исполнува три правила одеднаш.
Минимизирање на податоци (Чл. 5(1)(в)): Само колоните потребни за задачата одат до примателот. Идентификациските колони се бришат.
Ограничување на складирање (Чл. 5(1)(е)): Оригиналниот фајл останува за законско задржување. Чиста копија се прави за споделување — со пократко или без потреба за задржување.
Интегритет и доверливост (Чл. 5(1)(ж)): Никакви идентификациски податоци не ја напуштаат зоната на контрола. Само чисти копии се споделуваат.
Ревизискиот дневник од процесот е исто така вашиот доказ по Член 5(2). Покажува како секое правило беше исполнето за секој фајл.
Ако вашиот тим ракува со DSAR или големи извози на податоци, истата логика се применува на ниво на API. Видете како минимизирањето на GDPR податоци функционира во API-и во реално време.
За тимови кои ракуваат со висок обем под тесни рокови, видете Пакетна обработка на GDPR DSAR на скала за работни шеми кои и тука се применуваат.