E-posta Loglarını Saklamak: Ne Kadar Süre, Hangi Amaçla?

Bir müşteri "faturayı hiç almadım" diyor. Üç ay önce gönderilmiş bir ileti. Kaydınız var mı?

Gönderim logları, teslimat teşhisinden uyuşmazlık çözümüne kadar birçok yerde gerekir — ama sonsuza kadar saklanamaz. Bu yazı, e-posta log yönetimini anlatıyor.

Loglarda Ne Var?

Üçüncü ve dördüncü satırlar özel dikkat gerektirir: etkileşim kayıtları kişisel veri niteliğindedir ve ileti içeriği en hassas kategoridir. İçeriği saklamak, teslimat teşhisi için nadiren gereklidir — üst veri genellikle yeterlidir.

Beşinci satırda gizli bir risk vardır: hata kayıtları bazen bağlantı bilgilerini, kimlik doğrulama detaylarını ve hatta şifreleri loga yazabilir. Log dosyalarınızın erişimini kısıtlayın.

Neden Saklanır?

1. Teslimat teşhisi. "İleti gitti mi, ne oldu?" sorusuna cevap.
2. Uyuşmazlık çözümü. "Bildirimi göndermiştik" iddiasının kanıtı.
3. İzin kanıtı. Şikâyet durumunda kayıt tarihini ve onayını göstermek.
4. Performans analizi. Eğilimleri görmek için geçmiş veri.
5. Güvenlik incelemesi. Bir hesap ele geçirildiğinde ne gönderildiğini anlamak.
6. Yasal yükümlülükler. Sektöre göre belirli kayıtları saklama zorunluluğu.

İkinci ve üçüncü maddeler pratikte en çok kullanılanlardır: bir müşteri "bilgilendirilmedim" dediğinde veya bir şikâyet geldiğinde, kayıt olmadan savunma yapamazsınız.

Ne Kadar Süre?

Saklama süresi, kayıt türüne ve amaca göre farklılaşmalıdır. Genel bir yaklaşım:

• Teknik gönderim logları. Teşhis için birkaç hafta genellikle yeterlidir.
• Teslimat sonuçları. Birkaç ay — eğilim analizi ve gecikmeli şikâyetler için.
• İzin ve onay kayıtları. Abonelik devam ettiği sürece ve sonrasında makul bir süre.
• İleti içeriği. Mümkünse hiç saklamayın; gerekiyorsa mümkün olan en kısa süre.
• Özet metrikler. Uzun süre saklanabilir — kişisel veri içermez.

Son madde önemli bir strateji sunar: ayrıntılı kayıtları kısa süre, özetlenmiş ve anonimleştirilmiş metrikleri uzun süre saklayın. Böylece hem uzun vadeli eğilim analizini korur hem de kişisel veri saklama süresini kısaltırsınız.

Veri Minimizasyonu

Kişisel veri işlerken temel ilke şudur: gerekmeyen veriyi toplamayın, gerekmeyen süre saklamayın.

Pratik uygulamaları:

1. Kullanmayacağınız veriyi kaydetmeyin. Her tıklamanın konum bilgisini saklamanız gerekiyor mu?
2. Otomatik silme kuralları tanımlayın. Elle temizlik yapılmaz, unutulur.
3. Anonimleştirin. Eğilim analizi için kişi kimliğine gerek yoktur.
4. Erişimi kısıtlayın. Loglara kimler erişebiliyor?

İkinci madde uygulamanın anahtarıdır: saklama politikası belirlemek kolaydır, ona uymak zordur. Otomatik silme kurulmadıysa politika kâğıt üzerinde kalır ve loglar yıllarca birikir.

Veri Talepleri

Kullanıcılar, kendileri hakkındaki verilere erişim ve silme talebinde bulunabilir. Buna hazırlıklı olmak gerekir:

• Veriyi bulabilmelisiniz. Bir kişiye ait tüm kayıtları çıkarabilir misiniz?
• Silebilmelisiniz. Yedeklerdeki kopyalar dahil.
• Süre içinde yanıt vermelisiniz. Talepler için makul bir süre tanınır.
• İstisnaları bilmelisiniz. Bazı kayıtlar yasal zorunluluk nedeniyle saklanmaya devam edebilir.

İkinci madde teknik olarak zordur: yedeklerde de veri bulunur ve bunları seçici olarak silmek pratik değildir. Yaygın çözüm, yedeklerin de sınırlı süre saklanması ve bu sürenin belgelenmesidir.

Log Güvenliği

Loglar da korunması gereken verilerdir:

• Erişimi kısıtlayın. Herkesin okuyabildiği bir log dosyası, veri sızıntısı riskidir.
• Şifreleyin. Özellikle uzun süre saklanan arşivler.
• Hassas veriyi loglamayın. Şifreler, tam kart bilgileri, kimlik numaraları.
• Erişim kaydı tutun. Loglara kim erişti?
• Web erişimine kapatın. Log dosyaları tarayıcıdan okunabilir olmamalı.

Üçüncü madde en sık ihlal edilendir ve genellikle kasıtsızdır: bir hata oluştuğunda uygulama, tüm istek verisini loga yazar — içindeki hassas bilgilerle birlikte. Hata loglama davranışınızı gözden geçirin.

Beşinci madde de kritik bir kontroldür: log dosyaları web kök dizininde bulunuyorsa, doğrudan tarayıcıdan indirilebilir hâle gelir.

Pratik Bir Düzen

Sürdürülebilir bir log yönetimi için:

1. Kayıt türlerini sınıflandırın. Hangi veri, hangi amaçla tutuluyor?
2. Her tür için saklama süresi belirleyin. Amaca göre farklı süreler.
3. Otomatik silmeyi kurun. Süre dolduğunda kayıt otomatik silinsin.
4. Özet verileri ayrı saklayın. Uzun vadeli analiz için anonim metrikler.
5. Politikayı belgeleyin. Gizlilik politikanızda da belirtin.
6. Yılda bir gözden geçirin. İhtiyaçlar ve düzenlemeler değişir.

Dördüncü madde, en çok gözden kaçan ama en değerli adımdır: kişi bazlı kayıtları silerken, günlük toplam gönderim, açılma oranı ve şikâyet oranı gibi özet metrikleri saklamaya devam edin. Bunlar kişisel veri içermez ve yıllar sonra eğilim analizi için değerlidir.

Merkezi bir gönderim altyapısı kullanıyorsanız, saklama sürelerini ve otomatik silme kurallarını tek noktadan tanımlayabilirsiniz — farklı sistemlerde dağınık duran logları ayrı ayrı yönetmek, politikaya uyumu zorlaştırır.

Sonuç

E-posta logları, teslimat teşhisinden uyuşmazlık çözümüne kadar birçok yerde gerekir ama sonsuza kadar saklanamaz. Temel ilke veri minimizasyonudur: gerekmeyen veriyi toplamayın, gerekmeyen süre saklamayın. En pratik strateji katmanlıdır — ayrıntılı kişi bazlı kayıtları kısa süre, anonimleştirilmiş özet metrikleri uzun süre saklayın; böylece hem eğilim analizini korursunuz hem de kişisel veri yükünü azaltırsınız. Ve politikanın kâğıt üzerinde kalmaması için otomatik silme kurallarını mutlaka kurun.

Sıkça Sorulan Sorular (SSS)

E-posta loglarını ne kadar süre saklamalıyım?

Kayıt türüne göre değişmeli. Teknik gönderim logları için birkaç hafta teşhis amacıyla yeterlidir; teslimat sonuçları için birkaç ay makuldür. İzin ve onay kayıtları abonelik süresince tutulmalıdır. İleti içeriğini mümkünse hiç saklamayın.

İleti içeriğini saklamalı mıyım?

Teslimat teşhisi için nadiren gereklidir — üst veri (kime, ne zaman, sonuç ne oldu) genellikle yeterlidir. İçerik en hassas veri kategorisidir ve saklamak hem güvenlik hem uyum riski üretir. Gerekiyorsa mümkün olan en kısa süre tutun.

Saklama politikası belirlemek yeterli mi?

Değil. Otomatik silme kuralları kurulmadıysa politika kâğıt üzerinde kalır — elle temizlik yapılmaz, unutulur ve loglar yıllarca birikir. Süre dolduğunda kayıtların otomatik silinmesini sağlayın.

Loglarda hassas veri olabilir mi?

Sıkça olur ve genellikle kasıtsızdır. Bir hata oluştuğunda uygulama tüm istek verisini loga yazabilir — şifreler ve kimlik bilgileri dahil. Hata loglama davranışınızı gözden geçirin ve log dosyalarının web kök dizininde bulunmadığından emin olun.