İlgili kişi başvuruları: yasal süre, kaynaklar arası bulma ve kanıt

Bir ilgili kişi başvurusu, kurumun veri yönetimini en zor koşullarda sınar: saat işler, kişi bellidir, veri dağınıktır ve sonuç kanıtlanmak zorundadır. Başvuruyu kaçırmanın nedeni çoğunlukla isteksizlik değil, kişinin verisinin hangi sistemlerde olduğunu bilmemektir. Bu yazı başvuru sürecini adım adım ele alır, yasal sürenin neden kaçırıldığını açıklar ve veriyi kaynaklar arasında bulup kanıtlı yanıtlamanın operasyonel yolunu gösterir.

Bu yazı hukuki tavsiye değildir; yanıt süresi, istisnalar ve ret gerekçeleri hukuk biriminizle doğrulanmalıdır.

Başvuru nedir ve süreç nasıl işler

İlgili kişi, veri sorumlusuna başvurarak kendisiyle ilgili kişisel verinin işlenip işlenmediğini öğrenme, işlenmişse buna ilişkin bilgi talep etme, verinin düzeltilmesini, silinmesini veya yok edilmesini isteme gibi haklarını kullanır. Kurum’un “Kurul Karar Özetleri” sayfası, başvuruların ele alınışına ilişkin şikâyetlerin Kurul önüne geldiğini ve karara bağlandığını gösterir; bu, sürecin yalnızca bir iç prosedür değil, Kurum tarafından denetlenen bir yükümlülük olduğunu hatırlatır.

Süreç tipik olarak beş adımdan oluşur: başvurunun alınması ve kimlik doğrulaması, başvurunun kayda alınması ve sınıflandırılması (bilgi, düzeltme, silme), kişinin verisinin kurumun sistemlerinde bulunması, yanıtın ya da işlemin (düzeltme, silme, anonimleştirme) hazırlanıp onaylanması ve yanıtın iletilip kanıtının saklanması. Bu adımların her biri bir sorumluya, bir süreye ve bir kayda ihtiyaç duyar.

Kanun, veri sorumlusunun başvuruyu belirli bir süre içinde sonuçlandırmasını öngörür. Sürenin nasıl hesaplandığı ve hangi hâllerde uzayabileceği hukuk biriminin alanıdır. Operasyonun sorumluluğu, bu sürenin içinde kalmayı mümkün kılan hazırlığı önceden yapmış olmaktır.

Başvuru türleri ve operasyonel farkları

Başvurular hukuken tek bir çatı altında toplansa da operasyonel olarak üç farklı iş yükü üretir. Bilgi talebi, kişinin verisinin nerede ve hangi amaçla işlendiğini sorar; yanıt, kaynaklar arası eksiksiz bir arama ve redakte bir kopya gerektirir. Düzeltme talebi, belirli bir alanın (adres, telefon, ad) tüm kopyalarda güncellenmesini ister; asıl zorluk, güncellenmesi gereken kopyaların tamamını bulmaktır. Silme ya da yok etme talebi ise en ağır iş yüküdür: her kopyanın bulunması, hangisinin yasal saklama yükümlülüğü nedeniyle tutulacağının belirlenmesi, kalanların onaylı imhası ve tamamının kanıtlanması gerekir.

Bu üç tür için ortak olan tek şey, kişinin verisinin hangi sistemlerde olduğunu bilme zorunluluğudur. Bilgi talebinde bir sistemi atlamak eksik yanıt, düzeltmede atlamak tutarsız kayıt, silmede atlamak ise “silindi” denmiş ama silinmemiş veri demektir. Üçüncü durum, kişi aynı veriyle yeniden karşılaştığında Kurum’a şikâyet olarak döner.

Başvurunun türü, iş akışının başında doğru sınıflandırılmalı ve her tür için önceden tanımlı bir sorumlu, onay yetkisi ve kanıt şablonu bulunmalıdır. Türü yanlış kaydedilen bir başvuru, süreci yanlış yolda başlatır ve kaybedilen gün geri gelmez.

Yasal süre neden kaçırılır

Gecikmeler nadiren tek bir adımda birikir; sürecin her adımında küçük kayıplar toplanır. Birinci kayıp, başvurunun kayda girmesindeki gecikmedir. Başvuru bir şube e-postasına, bir çağrı merkezi notuna ya da bir noter yazısına gelir ve uyum ekibine ulaşması günler alır. Saat ise başvurunun kuruma ulaştığı anda işlemeye başlar.

İkinci ve en büyük kayıp, veriyi bulmaktır. Kişinin verisi CRM’de, bordro sisteminde, bir destek uygulamasında, dosya sunucusundaki sözleşme klasöründe, bir SharePoint kütüphanesinde, eski bir çalışanın PST arşivindeki yazışmalarda ve bir S3 kovasındaki yedekte olabilir. Her sistem için ayrı bir birime sorulması, her birimin elle araması ve sonuçların derlenmesi, sürenin büyük kısmını tüketir. Bir sistem unutulursa yanıt eksik olur; eksik yanıt, hiç yanıt vermemek kadar risklidir.

Üçüncü kayıp, yanıtın hazırlanmasıdır. Bulunan belgelerde üçüncü kişilerin verisi vardır; sözleşmede karşı taraf, e-postada diğer alıcılar, bordro listesinde diğer çalışanlar. Bunların maskelenerek redakte bir kopya üretilmesi elle yapıldığında hem yavaş hem hatalıdır. Dördüncü kayıp onaydır: silme talebinde hangi kopyanın silinebileceği, hangisinin yasal saklama yükümlülüğü nedeniyle tutulması gerektiği hukuk ve iş birimi arasında gidip gelir.

Adım	Tipik gecikme nedeni	Önceden yapılabilecek hazırlık
Alım ve kayıt	Başvuru yanlış kanala gelir	Tek kayıt noktası, tarih damgası
Bulma	Sistemler elle, birim birim aranır	Güncel keşif envanteri; kaynaklar arası arama
Yanıt hazırlama	Üçüncü kişi verisi elle maskelenir	Redakte kopya üretimi
Onay	Silme kapsamı tartışılır	Saklama takvimi; etiketlere bağlı kurallar
Kanıt	Ne yapıldığı dağınık e-postalarda	Başvuruya ekli denetim kaydı

Veriyi kaynaklar arasında bulmak

Başvuruya yanıt vermenin ön şartı, kişinin verisinin nerede olduğunu bilmektir. Bu bilgi iki düzeyde gerekir. Birinci düzey envanterdir: hangi sistemlerde hangi veri kategorileri bulunur? Bu, VERBİS envanterinin gerçek keşiften kurulmasıyla elde edilir ve başvuru gelmeden önce hazırdır. İkinci düzey kişi düzeyidir: bu belirli kişinin TCKN’si, e-postası, telefonu ya da adı hangi dosya, tablo ve iletide geçer?

İkinci düzey arama, keşif altyapısı olmadan yapılamaz. Dosya sunucularında, Microsoft 365’te, veritabanlarında, nesne depolamada ve posta arşivlerinde kişi tanımlayıcısıyla arama yapmak, her kaynağa salt okunur bağlanan ve içeriği önceden indekslemiş bir sistem gerektirir. Arama sonucu yalnızca “bulundu” değil, hangi kaynakta, hangi yolda, hangi veri türüyle ve hangi güven yüzdesiyle bulunduğu olmalıdır; aksi hâlde yanıtın eksiksizliği savunulamaz.

Bir örnek senaryo: bir perakende şirketine eski bir müşteriden silme talebi gelir. CRM kaydı silinir ve yanıt verilir. Aylar sonra aynı kişi, kendisine kampanya e-postası geldiğini belirterek Kurum’a şikâyette bulunur. İnceleme, kişinin verisinin bir pazarlama ajansına gönderilmek üzere hazırlanmış ve bir SharePoint kütüphanesinde kalmış bir Excel listesinde durduğunu gösterir. Liste envanterde değildir; kimse sormamıştır çünkü kimse bilmemektedir. Kaynaklar arası arama bu kopyayı ilk başvuruda bulurdu.

Redakte kopya ve işlemin yürütülmesi

Bilgi talebinde yanıt, kişinin verisini içeren belgelerin ya da kayıtların bir kopyasıdır; ancak bu kopya başka kişilerin verisini ifşa edemez. Redakte kopya, başvuru sahibine ait olmayan tanımlayıcıların ve başvuru kapsamı dışındaki bilgilerin maskelendiği sürümdür. Maskeleme, verinin hangi türde olduğunu bilen bir tespit motoru tarafından yapılmalı ve sonuç bir insan tarafından onaylanmalıdır.

Silme ya da yok etme talebinde işlem, kişinin verisinin bulunduğu her kopyaya uygulanır: üretim sistemindeki kayıt, dosya sunucusundaki dışa aktarım, posta arşivindeki ek, test veritabanındaki satır. Yasal saklama yükümlülüğü nedeniyle tutulması gereken kopyalar, saklama takvimi ve etiketler üzerinden belirlenir ve ret gerekçesi kayda geçer. Kurum’un “Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi” sayfası, silme, yok etme ve anonim hâle getirme yöntemlerinin çerçevesini verir; silme yerine anonimleştirme tercih edildiğinde, redakte kopya üretilip aslın imha edilmesi ve sonucun tekillik denetimiyle ölçülmesi gerekir.

Her işlem bir sorumluya atanmalı ve ayrı bir onay yetkisinden geçmelidir. Silmeyi öneren kişi ile onaylayan kişinin ayrılması, hem hatalı silmeyi hem de “silindi dendi ama silinmedi” durumunu önler.

Kanıt: ne yapıldığı değil, yapıldığının gösterilebilmesi

Başvuru kapatıldığında kurumun elinde şunlar olmalıdır: başvurunun alınma tarihi ve kanalı, kimlik doğrulama kaydı, hangi kaynaklarda arama yapıldığı ve ne bulunduğu, hangi işlemin kim tarafından önerilip kim tarafından onaylandığı, işlemin ne zaman tamamlandığı, redakte kopyanın hangi maskeleme kurallarıyla üretildiği ve yanıtın ne zaman iletildiği. Bu zincir, Kurum’a bir şikâyet geldiğinde kurumun tek savunmasıdır.

Kanıt, dağınık e-postalarda ve kişisel notlarda değil, başvuruya bağlı tek bir kayıtta durmalıdır. Denetim kaydı, kim, ne zaman, neden sorularını her adım için yanıtlamalı ve dışa aktarılabilmelidir. Kanıtın olmaması, işlemin yapılmamış sayılmasıyla aynı sonuca yol açabilir.

Kanıt zinciri, başvurunun kısmen ya da tamamen reddedildiği durumlarda daha da önemlidir. Ret gerekçesi, dayandığı saklama yükümlülüğü, kapsam dışı bırakılan veri ve kararı veren kişi aynı kayıtta yer almalıdır; aksi hâlde kurum, haklı bir reddi bile savunamaz. Kısmi yanıtlarda hangi kopyanın neden tutulduğu ve hangisinin imha edildiği, ilgili kişiye verilen yanıtla kurumun iç kaydı arasında tutarlı olmalıdır.

Seratus bu açıkları nasıl kapatır

Açık 1: Kişinin verisinin hangi sistemlerde olduğu bilinmiyor. Seratus’un KVKK takımı başvuruyu kayda alır ve kişinin verisini bağlı tüm kaynaklarda arar: dosya sunucuları, Windows/Linux/macOS yerel diskleri, Microsoft 365, Oracle, SQL Server, PostgreSQL/MySQL, S3-uyumlu depolama ve PST/OST/MSG arşivleri. Bağlantılar salt okunurdur; keşif, ajansız yürütülür.

Açık 2: Türkçe tanımlayıcılarla arama güvenilir değil. Türkçeye özel tespit motoru TCKN, telefon, e-posta ve IBAN gibi tanımlayıcıları bağlamıyla bulur; her bulgu güven yüzdesi ve maskeli örnekle listelenir. Veritabanlarında “örneklemde bulunmadı” bir risk kararı olarak sunulmaz; bulgu durumu açıkça belirtilir.

Açık 3: Redakte kopya elle hazırlanıyor. Seratus, başvuru sahibine ait olmayan tanımlayıcıları maskeleyerek redakte kopya üretir; maskeleme sınıflandırma etiketlerine dayanır ve insan onayından geçer. İsteğe bağlı özel, yerinde LLM başvuru özetini zenginleştirir; dış AI servisine veri gitmez.

Açık 4: Silme kapsamı ve onayı belirsiz. Silme, yok etme ve anonimleştirme eylemleri sorumluya atanır ve ayrı onay yetkisiyle yürütülür. Saklama takvimi, yasal saklama yükümlülüğü nedeniyle tutulması gereken kopyaları etiket üzerinden gösterir; anonimleştirmede redakte kopya üretilip aslı imha edilir ve kalite tekillik denetimiyle ölçülür.

Açık 5: Süresi geçmiş başvurular fark edilmiyor. KVKK hazırlık puanındaki “açıklar” listesi, süresi geçmiş başvuruları ayrı bir madde olarak gösterir. Başvurular SIEM ve talep yönetimi sistemlerine iletilebilir; ekipler mevcut iş akışlarında takip eder.

Açık 6: Kanıt dağınık. Her arama, bulgu, redaksiyon, onay ve işlem kim, ne zaman, neden bilgisiyle denetim kaydına yazılır ve başvuruya eklenir. Denetim raporu ve kaynak bazlı detay PDF, Excel veya CSV olarak dışa aktarılır.

Sonuç

İlgili kişi başvurusu, kurumun envanterinin ve keşif altyapısının gerçek bir sınavıdır. Süre, veriyi bulmak için harcanan zamanla tükenir; eksik yanıt, bilinmeyen kopyalardan doğar; kanıt, dağınık e-postalarda kaybolur. Başvuru gelmeden önce keşfi yapmış, envanteri gerçek bulgulardan kurmuş ve her işlemi onaylı ve kayıtlı yürüten bir kurum, başvuruyu süresi içinde ve savunulabilir biçimde kapatır. Seratus bu süreci tek konsolda, kurumun kendi altyapısında yürütür.