Çoğu kurum veri korumasını bir belge egzersizi gibi ele alır. Bir gizlilik politikası yazılır, bir çerez banner'ı konur, bir klasör dolusu PDF dosyalanır — ve herkes kutunun işaretlendiğini varsayar.

Sonra bir ilgili kişi, hakkında tuttuğunuz her şeyi görmek ya da sildirmek ister; ve işlerin gerçek hâli ortaya çıkar: kişisel verinin aslında nerede durduğunu kimse tam bilmiyordur.

DZDSoft'ta veri güvenliği, en çok talep edilen hizmetlerimizden biri ve tablo neredeyse hep aynı: politika iyi, altındaki sistem değil. Bu boşluğu kapatmayı nasıl düşündüğümüz aşağıda.

Kişisel veri, herkesin sandığından çok daha fazla yerde saklanır

Gizlilik politikası düzenli versiyonu anlatır: bir CRM, bir İK sistemi, bir müşteri veritabanı. Gerçek daha dağınıktır. Kişisel veri şuralarda birikir:

• Bireysel dizüstülerdeki ve paylaşımlı sürücülerdeki excel'ler.
• E-posta gelen kutuları ve ekleri, süresiz.
• Kopyaladıkları kayıttan daha uzun yaşayan veritabanı backup'ları.
• Uygulama logları, analytics event'leri, destek kayıtları.
• Kimsenin kapatmadığı ama herkesin hâlâ güvendiği eski sistemler.

Bu, gölge-veri (shadow data) problemidir ve veri keşfinin — ne tuttuğunu ve nerede tuttuğunu bilmenin — neden her ciddi uyum çalışmasının ilk gerçek adımı olduğunu açıklar. Bulamadığınız veriyi koruyamaz, silemez ya da raporlayamazsınız.

Üç zor problem: keşif, silme, arşivleme

Hukuki dili bir kenara koyduğunuzda hem KVKK hem GDPR üç somut teknik yetenek ister. Diğer her şey bunların üzerine kurulur.

Rahatsız edici gerçek şu: çoğu kurum üçünü de anlatabilir ama hiçbirini güvenilir biçimde uygulayamaz. Anlatmak politika işidir. Uygulamak mühendisliktir — ve genelde eksik olan kısım budur.

KVKK ve GDPR: aynı omurga, farklı ayrıntılar

Türkiye ve AB'de faaliyet gösteren kurumlar için — ki müşterilerimizin çoğu böyle — iyi haber şu: KVKK (6698 sayılı Kanun) ve GDPR aynı omurgayı paylaşır. Birini düzgün kurarsanız diğerinin büyük kısmını da kurmuş olursunuz.

Ayrıntıda ayrışırlar: KVKK'nın kendi kayıt yükümlülüğü (VERBİS), açık rıza ve yurt dışına aktarım için kendi kuralları, kendi denetim otoritesi vardır. GDPR daha ağır azami cezalar ve daha gelişmiş bir rehberlik gövdesi taşır. Ama alttaki mühendislik — envanter, hukuki dayanak, saklama, erişim kontrolü, ihlal müdahalesi — iki değil, tek sistemdir.

Bu yüzden paralel iki uyum programı sürdürmek yerine her eksende daha katı olan gereksinime göre kurarız. Hangisi daha sıkıysa onu karşılayacak şekilde yapılandırılmış tek ve iyi mühendislik edilmiş bir veri katmanı, yarım bakımlı iki katmandan daha ucuz ve daha güvenlidir.

Bunu sisteme gömmek

Bir denetimden geçen veri koruması, sona eklenen bir özellik değildir. Verinin baştan nasıl saklanıp taşındığına tasarlanan bir dizi özelliktir — mevzuatın kendi deyimiyle tasarımdan veri koruması (data protection by design). Pratikte:

• Envanterin geçen yılın organizasyon şemasını değil gerçeği yansıtması için güncel kalan data mapping.
• Arşiv ve silmenin hafızayla değil otomatik olması için oluşturulma anında veriye iliştirilen saklama kuralları.
• Erişim kontrolü — least privilege, gerçek kimlik doğrulama (uygun yerde SSO/LDAP) — doğru kişilerin doğru kayıtlara ulaşması için.
• Kimin neye eriştiğini kaydeden bir audit trail — "uyumlu olduğumuzu sanıyoruz"u "işte log"a çevirir.
• Beklemede ve aktarımda şifreleme, ham kimliğe gerek olmayan yerde pseudonymization.

Bunların hiçbiri egzotik değil. Çoğu ekibin yalnızca kâğıt üstünde ele aldığı bir probleme uygulanmış disiplinli mühendislik.

Ne zaman bir veri güvenliği projesine ihtiyacın var?

Her kurumun tam kapsamlı bir çalışmaya ihtiyacı yoktur. Muhtemelen şu durumlarda vardır:

Bunlardan ikisi ya da fazlası doğruysa, politikan ile sistemlerin arasındaki boşluk; bir talebin, denetimin ya da ihlalin ortaya çıkarmasını bekleyen bir yükümlülüktür.

Biz nasıl yaklaşıyoruz?

Uyumu bir veri mühendisliği problemi olarak ele alıyoruz, çünkü öyle. Bir veri güvenliği çalışmasında işimiz önce keşif — kişisel verinin gerçekte nerede yaşadığını haritalamak — sonra keşfi, silmeyi ve saklamayı otomatik ve kanıtlanabilir kılan mekanizmaları kurmaktır. Biz mühendisiz, hukuk bürosu değil: hukuki görüşünü biz yazmayız; hukuki konumunun gerçekten ayakta durmasını sağlayan sistemi kurarız.

Cephe yazılımına ve özel geliştirmeye getirdiğimiz aynı disiplin burada da geçerli. Sistemde gösteremediğin bir uyum iddiası, uyum değildir — bir temennidir. Bizim işimiz onu yazılımın bir özelliğine çevirmek.