KVKK Veri İşleme Envanteri Nasıl Hazırlanır — VERBİS Bağlantılı Rehber

Veri işleme envanterinin zorunlu alanları, Excel ile canlı envanter farkı, VERBİS m.16 kayıt yükümlülüğü ve sürdürülebilir uyum adımları.

VERBİS kayıt süresi yaklaştığında birçok kurum aynı soruyla karşılaşır: “Envanterimiz var, neden hâlâ eksik sayılıyoruz?” Cevap genellikle dosyanın kendisinde değil, dosyanın canlılığında yatar. İK departmanı yeni bir SaaS aracı devreye almış; pazarlama ekibi farklı bir analitik aracına geçmiş; IT yedekleme politikasını buluta taşımış — ancak Excel’deki envanter tablosu hâlâ 2023 sütunlarıyla duruyor. KVKK kapsamında veri işleme envanteri, bir kerelik doldurulup rafa kaldırılan bir belge değil; m.10 aydınlatma yükümlülüğü, m.12 güvenlik tedbirleri, m.16 VERBİS beyanı ve m.9 yurt dışı aktarım analizinin ortak dayanağıdır.

Bu rehber, envanterin zorunlu alanlarını, Excel ile “canlı envanter” arasındaki farkı, VERBİS bağlantısını ve sürdürülebilir bir envanter programını adım adım açıklar.

Veri İşleme Envanteri Neden Zorunlu?

6698 sayılı KVKK’da “veri işleme envanteri” ifadesi tek bir maddede tanımlanmış bir form adı olarak geçmez; ancak Kanun’un bütüncül mantığı envanter tutmayı fiilen zorunlu kılar:

  • m.10 (Aydınlatma): İlgili kişiye hangi verilerin hangi amaçla işlendiğini bildirmek için bu bilgilerin kurum tarafından sistematik biçimde bilinmesi gerekir.
  • m.12 (Veri güvenliği): Tedbirler, işlenen veri kategorilerine, hacme, saklama ortamına ve erişim profiline göre belirlenir; bunun için envanter şarttır.
  • m.16 (VERBİS): Belirli eşikleri aşan veri sorumluları sicile kayıt olurken işleme faaliyetlerini beyan eder; beyanın kaynağı envanterdir.
  • m.5 (İşleme ilkeleri): Amaçla sınırlılık, ölçülülük ve saklama süresi ilkelerine uyum, envanter olmadan denetlenemez.
  • m.9 (Yurt dışı aktarım): Aktarımın varlığı, alıcı ülke ve güvence mekanizması envanter kayıtlarında izlenmelidir.

Envanter eksikliği veya güncelliğini yitirmiş envanter, 2026 KVKK idari para cezası tablosunda VERBİS (341.809 – 17.092.242 TL) ve veri güvenliği (256.357 – 17.092.242 TL) ceza bantlarıyla doğrudan kesişen bir risktir.

Envanter Kaydında Bulunması Gereken Alanlar

KVKK ve Kişisel Verileri Koruma Kurulu rehberleri çerçevesinde her işleme faaliyeti için envanter satırında asgari olarak şu bilgiler yer almalıdır:

AlanAçıklamaÖrnek
Faaliyet / süreç adıİşleme faaliyetinin kurumsal adıMüşteri sipariş yönetimi
İşleme amacıVerinin neden işlendiğiSözleşmenin ifası, yasal yükümlülük
Hukuki sebepKVKK m.5 kapsamında dayanakm.5/2-c, m.5/2-ç, açık rıza
Veri kategorisiİşlenen kişisel veri türleriKimlik, iletişim, finans
Özel nitelikli verim.6 kapsamında olup olmadığıEvet/Hayır; varsa tür
İlgili kişi grubuVerisi işlenen kişi kitlesiMüşteriler, çalışan adayları
Veri toplama yöntemiVerinin elde edilme kanalıWeb formu, sözleşme, kamera
Veri alıcıları / aktarımÜçüncü taraflar, grup şirketleriKargo firması, muhasebe SaaS
Yurt dışı aktarımm.9 kapsamında aktarım var mıEvet; ABD, AWS bölgesi
Saklama süresiSilme/imha zamanlaması10 yıl (VUK), sözleşme bitimi + 2 yıl
Teknik/idari tedbirlerm.12 kapsamında önlemlerŞifreleme, RBAC, eğitim
Veri sorumlusu / işleyen rolüRolünüz ve tedarikçi rolüVeri sorumlusu; XYZ veri işleyen

Her satır tek bir amaca hizmet etmelidir. “Müşteri verileri” gibi geniş kategoriler, denetimde yetersiz kabul edilir; faaliyet bazlı ayrıştırma gerekir.

Adım Adım Envanter Oluşturma Süreci

1. İş süreçlerini haritalayın

Envanter, IT envanterinden farklıdır; departman süreçleriyle başlar. Satış, İK, finans, pazarlama, operasyon ve hukuk birimleriyle kısa görüşmeler yaparak kişisel veri içeren süreçleri listeleyin. “Veri yok” cevabını doğrulamak için somut sorular sorun: hangi formlar, hangi yazılımlar, hangi raporlar?

2. Veri kategorilerini netleştirin

Her süreçte hangi veri alanlarının işlendiğini tespit edin. TCKN, e-posta, telefon gibi temel alanların yanı sıra konum, görüntü kaydı, biyometrik veri gibi özel nitelikli verileri ayrı işaretleyin. İşyeri güvenlik kamerası KVKK uyumu rehberimiz, görüntü kaydı gibi sık gözden kaçan faaliyetlerin envantere nasıl girmesi gerektiğini somut örneklerle anlatır.

3. Hukuki sebebi atayın

Her işleme faaliyeti için m.5 kapsamında en az bir hukuki sebep belirleyin. Açık rıza her zaman zorunlu değildir; ancak rıza gereken durumlarda (pazarlama iletişimi, çerez, biyometrik mesai takibi vb.) rıza mekanizmasının envanterde referanslanması gerekir. Mesai takibinde biyometrik veri gibi özel nitelikli veri senaryolarında hukuki sebep analizi kritik önem taşır.

4. Alıcı ve aktarım zincirini çıkarın

Veriyi kimlerle paylaştığınızı, hangi tedarikçilerin veri işleyen olduğunu ve alt-işleyen zincirini kaydedin. Bulut barındırma, e-posta servisi, CRM, muhasebe yazılımı ve destek hizmetleri tipik veri işleyenlerdir. Veri işleyen DPA ve tedarikçi risk yönetimi rehberimiz, envanterdeki alıcı sütununun sözleşme ve denetim süreciyle nasıl bağlanacağını açıklar.

5. Saklama süresi ve imha politikasını eşleştirin

Her faaliyet için saklama süresini mevzuat veya iş ihtiyacıyla gerekçelendirin. Süresi dolan verinin silinmesi veya anonimleştirilmesi için sorumlu birim ve periyot belirleyin. Süresiz saklama, m.5 ihlali olarak değerlendirilebilir.

6. Tedbirleri faaliyet bazında dokümante edin

m.12 kapsamında alınan teknik ve idari tedbirleri genel bir “güvenlik politikası” yerine faaliyet veya sistem bazında envantere bağlayın. Örneğin müşteri veritabanı için şifreleme, erişim loglama ve yedekleme; kamera kayıtları için erişim kısıtı ve saklama süresi otomasyonu.

Excel’de Tutulan “Ölü Envanter” vs. Canlı Envanter

Kurumların büyük çoğunluğu envantere bir Excel veya Google Sheet ile başlar. Bu başlangıç için kabul edilebilir; ancak “ölü envanter” ile “canlı envanter” arasındaki fark, uyum programının başarısını belirler.

Ölü envanterin tipik belirtileri

  • Son güncelleme 12 aydan eski
  • Yeni devreye alınan yazılımlar listede yok
  • Ayrıldı/iptal edildi tedarikçiler hâlâ alıcı sütununda
  • VERBİS beyanı ile satır içerikleri uyuşmuyor
  • Aydınlatma metninde geçen amaçlar envanterde karşılık bulmuyor
  • Sorumlu kişi/birim bilgisi boş veya güncel değil
  • Saklama süreleri “belirsiz” veya “süresiz”

Ölü envanter, denetim anında “ihmal” veya “sistematik eksiklik” algısı yaratır; idari para cezası riskini artırır.

Canlı envanterin özellikleri

  • Yeni süreç veya tedarikçi devreye girdiğinde tanımlı tetikleyici ile güncellenir
  • Aydınlatma metni versiyonları envanter satırlarına referans verir
  • VERBİS beyanı doğrudan envanterden türetilir (manuel kopya değil)
  • Değişiklik geçmişi (kim, ne zaman, ne değiştirdi) saklanır
  • Periyodik gözden geçirme takvimi vardır (ör. çeyreklik)
  • IT değişiklik yönetimi (change management) ile entegre çalışır

Canlı envanter, bir dosya formatı değil; operasyonel bir süreçtir.

VERBİS ve m.16: Envanterin Resmi Yansıması

KVKK m.16, Kişisel Verileri Koruma Kurulu tarafından belirlenen eşiklerin üzerindeki veri sorumlularının Veri Sorumluları Siciline kayıt yükümlülüğünü düzenler. VERBİS başvurusunda beyan edilen işleme faaliyetleri, envanterinizin özetidir.

Pratikte dikkat edilmesi gerekenler:

  1. Eşik analizi: Çalışan sayısı, yıllık mali bilanço veya faaliyet alanına göre kayıt yükümlülüğünüz olup olmadığını doğrulayın.
  2. Beyan-envanter tutarlılığı: VERBİS’te beyan ettiğiniz amaç, veri kategorisi ve alıcı bilgileri envanter satırlarıyla birebir örtüşmelidir.
  3. Güncelleme yükümlülüğü: İşleme faaliyetlerinde değişiklik olduğunda VERBİS kaydının güncellenmesi gerekir; bu da envanterin canlı kalmasını zorunlu kılar.
  4. İspat: Denetimde “VERBİS’e kayıtlıyız” demek yeterli değildir; kayıt içeriğinin güncel ve doğru olduğunu envanter ve aydınlatma metinleriyle ispat etmelisiniz.

VERBİS kayıt yükümlülüğünün ihlali, 2026 itibarıyla 341.809 – 17.092.242 TL ceza bandına tabidir. Envanter yatırımı, bu riskin ötesinde m.12 ve m.10 ihlallerini de önler.

Envanterin Kör Noktası: Sistemde Ne Var, Bilmiyoruz

Envanterin en zor aşaması kategori yazmak değil; dağınık sistemlerde hangi kişisel verinin nerede tutulduğunu keşfetmektir. İK’nın bildiği süreçler ile IT’nin yönettiği veritabanları arasında boşluk olabilir. Eski test ortamları, yedeklemeler veya departman bazlı “gölge IT” uygulamaları envanter dışında kalabilir.

Bu noktada otomatik PII keşfi devreye girer. Lexidata LexiAgent, on-prem Docker agent ile SQL veritabanlarını tarayarak kişisel veri metadata’sını tespit eder; ham veri dışarı çıkmaz, yalnızca keşif sonuçları platforma aktarılır. Kişisel veri keşfi ve PII tarama rehberimizde bu yaklaşımın envanter kalitesini nasıl artırdığını detaylandırdık.

Departman Bazlı Envanter Kontrol Listesi

Envanter oluştururken birim bazlı hızlı kontrol listesi:

İnsan Kaynakları

  • Aday başvuru formları ve özgeçmiş saklama
  • Çalışan özlük dosyası ve bordro verileri
  • Performans değerlendirme kayıtları
  • Mesai/PDKS ve biyometrik veri (varsa)

Pazarlama ve Satış

  • CRM kayıtları ve lead formları
  • E-posta pazarlama listeleri
  • Çerez ve analitik araçları
  • Sosyal medya etkileşim verileri

Finans ve Hukuk

  • Müşteri/tedarikçi sözleşmeleri
  • Fatura ve ödeme kayıtları
  • Hukuki süreç ve dava dosyaları

IT ve Operasyon

  • Log kayıtları ve erişim izleri
  • Yedekleme ve felaket kurtarma kopyaları
  • Güvenlik kamerası kayıtları
  • Bulut ve SaaS uygulama envanteri

Tedarikçi Yönetimi

  • Veri işleme sözleşmeleri (DPA) imza durumu
  • Alt-işleyen listeleri
  • Yurt dışı aktarım güvenceleri

Envanteri Sürdürülebilir Kılmak: Rol ve Sorumluluklar

Canlı envanter için net rol dağılımı şarttır:

RolSorumluluk
Veri koruma sorumlusu / uyum ekibiEnvanter metodolojisi, kalite kontrol, VERBİS tutarlılığı
İş birimi sahipleriSüreç değişikliklerini bildirme, satır içeriğini doğrulama
IT / bilgi güvenliğiSistem envanteri, tedbir uygulaması, keşif taramaları
HukukHukuki sebep analizi, DPA ve aktarım güvenceleri
Satın almaYeni tedarikçi devreye almadan önce gizlilik değerlendirmesi

Değişiklik yönetimi kuralı önerisi: Kişisel veri işleyen yeni bir sistem, tedarikçi veya süreç devreye alınmadan envanter satırı açılmadan go-live yapılmaz.

Sık Yapılan Hatalar

  1. Tek satırda tüm müşteri verisi: Faaliyet bazlı ayrıştırma yapılmaması.
  2. Hukuki sebebin kopyala-yapıştır: Her amaç için ayrı analiz yapılmaması.
  3. Tedarikçiyi unutmak: Veri işleyen rolü ve DPA envantere yansıtılmaması.
  4. Saklama süresi belirsizliği: “Yasal zorunluluk” ifadesiyle geçiştirme.
  5. Envanter-aydınlatma kopukluğu: Web metninde olmayan faaliyetlerin gizli işlenmesi.
  6. Yıllık güncelleme yanılsaması: Canlı değişikliklerin takip edilmemesi.

Bu hataların her biri, ayrı ceza riskleri doğurabilir; bütüncül envanter yaklaşımı hepsini tek çatı altında yönetir.

Lexidata Uyum Paneli ile Canlı Envanter

Lexidata uyum paneli, veri işleme envanterini statik dosya olmaktan çıkarıp operasyonel bir kaynağa dönüştürür:

  • Faaliyet bazlı envanter kayıtları — amaç, hukuki sebep, veri kategorisi, alıcı, saklama süresi, tedbir alanları
  • Aydınlatma metni yönetimi — envanter satırlarıyla bağlantılı, versiyonlu metin takibi
  • Başvuru ve süre takibi — ilgili kişi talepleri ile envanter tutarlılığı
  • VERBİS hazırlık desteği — envanterden türetilen tutarlı beyan altyapısı
  • LexiAgent entegrasyonu — veritabanı PII keşfi ile envanterin teknik doğrulaması

Envanterinizi bir kez doldurup unutmak yerine, iş süreçlerinizle birlikte yaşayan bir kayıt sistemi kurmak 2026 KVKK ceza ortamında en rasyonel uyum yatırımıdır. platform.lexidata.io adresinden uyum panelini inceleyebilirsiniz.

Diğer yazılar