Periyodik KVKK Teknik Sağlık Kontrolü: Internal Audit ve Otomatik Kontrol Listeleri

KVKK teknik sağlık kontrolü (internal audit) nedir?

Kısa yanıt: KVKK teknik tedbirlerinin gerçek sistemlerde hâlâ çalıştığını doğrulayan, tekrarlanan bir kontrol döngüsüdür. Bir audit; sadece “tarama” değil, bulgu→aksiyon→kapanış kanıtı→takip şeklinde yaşayan bir süreçtir. Periyodik yapılmadığında, en iyi tasarlanmış KVKK mimarisi bile zamanla bozulur. Bu nedenle web ve yazılım hizmetlerinde periyodik uyum denetimi, yeni form, entegrasyon, rol ve ölçümleme değişikliklerinden sonra tekrar eden bir operasyon olarak ele alınmalıdır.

Sağlık kontrolünün 3 amacı

1. Bozulan kontrolü yakalamak: log çalışmıyor, backup başarısız, MFA kapalı
2. Yeni riskleri görmek: yeni vendor, yeni script, yeni erişim rolleri
3. Denetim/olay hazırlığı: kanıt setini hazır tutmak

“KVKK sürekli süreç” yaklaşımı

Vulnerability taraması, rol review, log testi, backup testi, script envanteri ve config kontrolü; tek bir KVKK teknik internal audit modeli içinde birleşir: ölç → bul → düzelt → doğrula → kaydet → tekrar et.

☑ Mini Check :

• •Audit döngüsü tanımlı mı (yıllık/6 aylık)?
• •Otomatik taramalar planlı mı?
• •Manuel kontrollerin sahibi belli mi?
• •Bulgular için ticket ve SLA var mı?
• •Kapanış kanıtı standardı var mı?

Bir internal audit’i sürdürülebilir yapan şey; takvim ve rol sahipliğidir. “IT bakar” demek yetmez: rol listesi review için sistem owner, backup testi için infra owner, script envanteri için web/pazarlama owner gerekir. Otel ve B2B’de çok sistemli yapı olduğu için sorumluluklar dağıtılmalıdır. Denetim kapsamını netleştirmek için önce bir internal audit checklist üzerinden hangi başlıkların her döngüde kontrol edileceği sabitlenmelidir.

Önerilen döngü

• •Yıllık büyük audit: tam kapsam (tüm sistemler)
• •6 aylık ara audit: kritik kontroller (rol/log/backup/script/vendor)
• •Aylık mikro kontroller (opsiyonel): log heartbeat, backup success, MFA raporu

Timeline yaklaşımı (Media ile destek)

Audit döngüsünü timeline olarak görselleştirmek, ekiplerin “ne zaman ne var?” sorusunu netleştirir ve unutmayı azaltır.

☑ Mini Check :

• •Yıllık audit tarihi takvimde mi?
• •6 aylık ara audit planlı mı?
• •Owner’lar atanmış mı?
• •Aylık mikro kontroller tanımlı mı?
• •Bulguların follow-up planı var mı?

Otomatik tarama ve manuel kontrolü nasıl dengelemeliyim?

Kısa yanıt: otomatik kontrolleri “sürekli sinyal” olarak kullanın; manuel kontrolleri ise “bağlam ve karar” için periyodik uygulayın. Otomatik araçlar zayıf konfigürasyonu bulur; ama risk değerlendirmesi ve düzeltme planı insan gerektirir. Kapanan ve tekrar eden bulguların izlenmesi için de internal audit KPI ve trend analizi yaklaşımı kurulmalıdır.

Otomatik kontrol türleri (örnek)

• •Vulnerability scan (zafiyet taraması)
• •Misconfiguration tespiti (public bucket, açık portlar, zayıf policy)
• •Zayıf şifre politikası/hesap hijyeni raporu (MFA yok, eski hesap)
• •Log review otomasyonu (heartbeat, anomali)

Kritik pratik: false positive yönetimi

Her tarama bulgusu gerçek risk değildir. Bu yüzden bulgular triage edilmeli (P1/P2/P3) ve kapanış kanıtı zorunlu olmalıdır.

☑ Mini Check :

• •Tarama araçları ve sıklığı belirli mi?
• •Bulgular triage ediliyor mu?
• •False positive etiketi ve gerekçesi var mı?
• •Kapanış doğrulaması yapılıyor mu?
• •Kritik bulgular için SLA var mı?

Otomasyon sinyal verir; manuel kontrol doğrular ve düzeltir. KVKK’da “teknik tedbirler”in en çok bozulduğu yerler genelde manuel kontrol alanlarıdır: erişimler şişer, script’ler artar, backup restore yapılmaz, loglar sessizce durur. Bu nedenle erişim ve log konfigürasyon kontrolü ile birlikte script tarafında da Tag Manager konfigürasyon review yapılmalıdır.

Rol ve kullanıcı listesi review

• •Kimler admin?
• •Yetki fazlalığı var mı?
• •Ayrılan çalışan hesapları kapalı mı?

Logların çalışıp çalışmadığı testi (log heartbeat)

• •Login/export log’ları geliyor mu?
• •Kritik sistemler log üretiyor mu?
• •Log erişimi kısıtlı mı?

Script/tag envanteri kontrolü

• •3rd party script’ler GTM altında mı?
• •Consent’e bağlı tetikleme çalışıyor mu?
• •Gereksiz script temizliği yapıldı mı?

Yedekleme testleri

• •Backup var mı?
• •Restore test edildi mi?
• •Backup şifreli mi ve erişim kısıtlı mı?

☑ Mini Check :

• •Admin listesi güncel ve minimal mi?
• •Export işlemleri loglanıyor mu?
• •Consent sonrası script tetikleme test edildi mi?
• •Backup restore testi yapıldı mı?
• •Bulgular için follow-up planı yazıldı mı?

Hangi başlıklar periyodik olarak kontrol edilmeli?

Kısa yanıt: script’ler, roller, loglar, backup’lar, konfigürasyonlar, vendor erişimleri ve export süreçleri. Bu başlıklar hem KVKK hem de güvenlik açısından “çekirdek” kontrol alanlarıdır. İç denetimi güçlü yapan şey, bulgudan kapanışa giden net bir iş akışıdır: bulgu → risk → aksiyon → doğrulama → kanıt. Bu akışın çıktıları KVKK kontrol bulgularının raporlanması ve denetim için log bundle hazırlığı ile somut hale gelir.

“Follow-up planı” zorunlu olmalı

Checklist’i yapmak yetmez; her bulgu için owner, due date ve kapanış kanıtı yazılmalıdır. Aksi halde audit “rapor üretme”ye dönüşür.

Key Data Point (yumuşatılmış)

Periyodik internal audit kültürü olan kurumlarda, KVKK teknik tedbirleri “sadece dokümanda” kalmıyor; sistemler ve ayarlar gerçekten uyumlu tutulabiliyor. Bu da resmi denetimde ve incident anında hazırlıksız yakalanma riskini düşürüyor.

☑ Mini Check :

• •Checklist sabit başlıkları içeriyor (rol/log/backup/script/config)
• •Otomatik taramalar ve manuel kontroller dengeli
• •Bulgular ticket’lanıyor
• •Her bulgu için owner + due date var
• •Kapanış kanıtı zorunlu
• •Yıllık güncelleme ve kapsam revizyonu var (365 gün)

Teknik not: Teknik sağlık kontrolü; veri güvenliği, erişim review, export kanıtı ve KPI takibiyle entegre yürütülmeli; bulgular hukuki risk analiziyle eşleştirilmeli ve follow-up planı mutlaka yazılı olmalıdır.

Bu denetim döngüsünü kurumunuza uyarlamak isterseniz KVKK uyum hizmetiyle periyodik teknik kontrol yapısını birlikte kurabilir, ek sorular için KVKK uyum hizmeti hakkında sık sorulan sorular sayfasına geçebilirsiniz.