Excel Neden En Yüksek Riskli Dosya Türünüz
Excel dosyaları, çoğu işletmedeki en büyük GDPR risklerinden birini oluşturuyor. Tıbbi kayıtlar satır başına daha hassas veri içerebilir. Ancak elektronik tablolar KKB'yi hızla biriktirir — ve uyumluluk ekipleri bunları çoğu zaman gözden kaçırır.
Excel dosyalarını yönetmeyi zorlaştıran üç şey var.
Hacim: Tek bir XLSX dosyası 50.000 satır ve 100 sütun içerebilir. Bu beş milyon hücredir. Hiçbir elle inceleme bunların hepsini kontrol edemez.
Izgaralı düzen: Metin tek yönde akar. Excel veriyi satırlar ve sütunlar arasında yayar. Kişisel veri bu ızgaranın herhangi bir yerinde gizlenebilir.
Karma içerik: Ücret bantları, departman kodları ve iş dereceleri, SSN'ler ve e-posta adresleriyle aynı dosyada yer alır. Her şeyi silmek dosyayı işe yaramaz hale getirir.
Uzun saklama: Personel listeleri ve müşteri kayıtları Excel'de yıllarca kalır. GDPR Madde 5(1)(e), verilerin "gerekenden daha uzun süre" tutulmaması gerektiğini belirtir. "İşe yarayabilir" diye tutulan dosyalar çoğu zaman bu noktanın çok ötesinde kalır.
Standart Metin Taramalarının Elektronik Tablolarda Neden Başarısız Olduğu
Metin analizi araçları belgeler için tasarlandı. Elektronik tablolarda birkaç yaygın şekilde bozulur.
SSN'in Sayı Olarak Depolanması Sorunu
Excel, Sosyal Güvenlik Numaralarını tireler olmadan (123456789) düz sayı olarak — metin olarak değil — kaydeder. ###-##-#### formatını bulmak üzere oluşturulmuş bir tarayıcı bunları kaçırır. İyi bir araç, "SSN" adlı bir sütundaki 9 haneli sayının Sosyal Güvenlik Numarası olduğunu bilmek zorundadır.
Tarihin Sayı Olarak Depolanması Sorunu
Excel tarihleri seri numarası olarak depolar. 6 Şubat 2024, 45329 olarak depolanır. Bir CSV dışa aktarması, "Doğum Tarihi" sütununda "45329" gösterecektir. Tarayıcı, değeri işaretleyebilmek için önce bu sayıyı gerçek bir tarihe dönüştürmelidir.
Kısmi SSN Sorunu
Bazı sistemler SSN'in yalnızca son dört hanesini gösterir (*--1234). Tam numara kilitli bir sütunda yer alır. Kısmi değer yine de anonimleştirilmelidir — tam SSN gibi görünmese bile.
Formül KKB Sorunu
Bazı hücreler KKB'yi diğer hücrelerden oluşturur. =CONCATENATE(B2," ",C2) içeren bir hücre tam adı gösterir. B ve C sütunlarını temizlerseniz, bu tam ad formül hücresinde hâlâ görünür. Yalnızca depolanan değerleri okuyan — formül bağlantılarını değil — bir araç KKB'yi yerinde bırakır.
Çok Sayfası Sorunu
Büyük bir çalışma kitabının beş sayfası olabilir: Müşteri Listesi, Siparişler, Destek Biletleri, Faturalama ve Analitik. Müşteri adları hepsinde görünür. Bir sayfadaki "John Smith" diğer tüm sayfalarda aynı belirteç — "PERSON_0047" — olmalıdır. İki farklı belirteç kayıt bağlantılarını bozar.
Sütun Başlıkları Bir Sinyal Olarak
Elektronik tablo KKB tespitindeki en iyi iyileştirme, sütun başlığı analizidir.
"SSN" adlı bir sütun, araca bu sütundaki tüm değerlerin Sosyal Güvenlik Numarası olduğunu söyler. Bu, değerler kısmi, tuhaf biçimlendirilmiş veya sayı olarak depolanmış olsa bile işe yarar.
| Sütun başlığı | Ne ifade eder |
|---|---|
| SSN / Sosyal Güvenlik / Vergi Kimliği | 9 haneli sayıları SSN olarak işle |
| E-posta / E-mail / E-posta Adresi | Kısmi e-posta kalıplarını bile işaretle |
| Telefon / Cep / Mobil | Herhangi bir telefon formatını kabul et |
| DOB / Doğum Tarihi / Doğum Günü | Seri numaralarını tarihe dönüştür |
| Ad / Soyad / Tam Ad | İsim tespiti eşiğini düşür |
| Adres / Cadde / Şehir / Posta Kodu | Yakındaki konum alanlarını birleştir |
| Hasta Kimliği / MRN / Kayıt Numarası | Sağlık kimliği kalıplarını uygula |
Sütun bağlamı, içerik taramasının yerini almaz. Ona eklenir. 100 değerli "SSN" adlı bir sütun: içerik taraması iyi biçimlendirilmiş 99'unu yakalar. Sütun bağlamı tuhaf görüneni yakalar.
Yapıyı Koru, İsimleri Kaldır
Çoğu Excel GDPR durumundaki amaç dosyayı yok etmek değildir. Kişisel veriyi soyarak dosyayı kullanışlı kılan kısımları korumaktır.
15.000 satırlık bir personel kayıt dosyası için bir uyumluluk görevlisinin ihtiyacı:
Kaldır:
- Çalışan adları → PERSON_XXXX belirteçleri
- SSN'ler → REDACTED
- E-posta adresleri → REDACTED
- Telefon numaraları → REDACTED
- Ev adresleri → REDACTED
Koru:
- Departman kodları
- İş unvanları (yalnızca genel roller)
- Ücret bantları (geniş kategoriler)
- Performans puanları (grup verisi)
- Başlangıç tarihleri (kıdem istatistikleri için)
- Yönetici kodları (takma adlaştırılmışsa)
"İnsanları adlandıran veri" ile "işleri tanımlayan veri" arasındaki farkı bilen bir araç, İK analizi için çalışmaya devam eden — ve GDPR veri minimizasyonu kurallarını karşılayan — bir dosya sunar.
Gerçek Dava: Birleşme ve Satın Almada İK Veri Transferi
Edinen şirket, hedef firmadan 40 sütunlu 15.000 satırlık bir XLSX içinde personel kayıtları alır. Dosyanın faydalar planlaması için dış bir İK firmasına gitmesi gerekiyor. GDPR, yalnızca bu görev için gereken verilerin paylaşılabileceğini belirtiyor.
İşlem öncesi: 40 sütun, tam adlar, SSN'ler, e-postalar, ev adresleri, acil durum kişileri ve banka bilgileri içeriyor.
Sütun bağlamı işlemi sonrası:
- 12 sütun doğrudan kişileri tanımlar (adlar, SSN'ler, e-postalar, telefon, adresler, banka verileri): tutarlı belirteçlerle değiştirildi
- 3 sütun dolaylı olarak kişileri tanımlar (personel kimliği, yönetici kodu, iş kodu): dosya içinde eşleşen takma adlı belirteçlerle değiştirildi
- 25 sütun toplu verilerdir (ücret bandı, departman, kıdem, derece): değiştirilmedi
Süre: 600.000 hücre için 8 dakika
Çıktı: Aynı XLSX düzeni, 40 sütun, 15'i anonimleştirilmiş, 25'i değişmemiş
Denetim günlüğü: Kullanılan varlık türü, güven puanı ve sütun sinyaliyle birlikte her işlemi gösteren hücre düzeyinde kayıt
İK firması, çalışması için eksiksiz bir veri seti alıyor — ad veya kimlik olmadan. Uyumluluk kaydı, yalnızca doğru verilerin paylaşıldığının kanıtını alıyor.
Bu zorluk Excel'e özgü değildir. Her dosya formatı kendine özgü biçimde başarısız olur. Dosya türleri genelinde bir bakış için format parçalanmasının KKB tespitini nasıl etkilediğine bakın.
Üç GDPR Madde 5 Kuralı, Tek Süreç
Yapılandırılmış elektronik tablo anonimleştirmesi üç kuralı aynı anda karşılar.
Veri minimizasyonu (Mad. 5(1)(c)): Görev için gereken sütunlar alıcıya gider. Tanımlayıcı sütunlar silinir.
Saklama sınırlaması (Mad. 5(1)(e)): Orijinal dosya hukuki saklama için kalır. Paylaşım için daha kısa veya saklama ihtiyacı olmayan temiz bir kopya oluşturulur.
Bütünlük ve gizlilik (Mad. 5(1)(f)): Hiçbir tanımlayıcı veri kontrol bölgesinden çıkmaz. Yalnızca temiz kopyalar paylaşılır.
Süreçteki denetim günlüğü aynı zamanda Madde 5(2) kanıtınızdır. Her kural için her dosyada kuralın nasıl karşılandığını gösterir.
Ekibiniz DSAR'ları veya büyük veri dışa aktarmalarını yönetiyorsa, aynı mantık API düzeyinde de geçerlidir. Gerçek zamanlı API'lerde GDPR veri minimizasyonunun nasıl çalıştığına bakın.
Sıkı son tarihler altında yüksek hacimlerle uğraşan ekipler için, burada da geçerli olan iş akışı kalıpları için ölçekte GDPR DSAR toplu işleme sayfasına bakın.