Exchange Server Supervisory Review Dava Yönetimi

Exchange Server Supervisory Review Dava Yönetimi, serinin önceki bölümlerinde ele aldığımız iletişim gözetimi, denetim izleri ve veri saklama süreçlerinin hukuki incelemelerle buluştuğu noktadır.

Önceki makalemiz olan Exchange Supervisory Review Microsoft Purview Geçiş Stratejileri bölümünde, mevcut denetim modelinin yeni bir platforma taşınırken nasıl korunması gerektiğini inceledik. Politika kapsamının doğru eşleştirilmesi, açık incelemelerin takip edilmesi ve denetim kayıtlarının kaybolmaması üzerinde durduk.

Ancak bir iletişim uygunsuz olarak işaretlendiğinde veya ciddi bir ihlal şüphesi oluştuğunda, kurumun cevaplaması gereken sorular değişir:

• Bu mesaj hangi olayın parçasıdır?
• İlgili başka iletişimler var mı?
• Hangi veriler korunmalıdır?
• İnceleme kararını kim, hangi gerekçeyle vermiştir?
• Hukuk ve uyum ekiplerine hangi kayıtlar sunulmalıdır?

Bu noktada Supervisory Review bulgusu, daha kapsamlı bir vaka incelemesinin başlangıcı olabilir. Bazı vakalar kurum içi değerlendirmeyle kapanırken, bazıları regülatör incelemesine, hukuki uyuşmazlığa veya dava sürecine dönüşebilir.

Dolayısıyla dava yönetimi, yalnızca şüpheli e-postaların bir klasörde toplanması değildir. Kapsam belirleme, veriyi koruma, delil toplama, inceleme, yetkilendirme ve kayıtların kontrollü biçimde paylaşılması birlikte ele alınmalıdır.

Bu makalede “dava yönetimi” ifadesini, hukuki incelemeleri destekleyen kurumsal veri ve süreç yönetimi anlamında kullanıyoruz. Bir iletişimin politika eşleşmesi üretmesi, tek başına hukuki ihlal veya suç tespiti anlamına gelmez.

Exchange Server Supervisory Review Dava Yönetimi bölümünde aşağıda ki bilgileri sizlere paylaşacağız.

1. Supervisory Review ile Dava Yönetimi Arasındaki İlişki

Supervisory Review, belirlenen politikalar doğrultusunda seçilen iletişimlerin uygunluk açısından değerlendirilmesini sağlar.

Dava yönetimi ise belirli bir olayın, iddianın veya uyuşmazlığın etrafında daha geniş bir inceleme yürütülmesini gerektirir.

İki süreç birbirini tamamlar, ancak kapsamları farklıdır.

1.1 Denetim Bulgusu Nasıl Bir Vakaya Dönüşür?

Bir inceleyici, müşteri yazışmasında kurumun onaylamadığı bir taahhüt fark edebilir. Başka bir mesajda henüz açıklanmamış finansal bilgi paylaşımı veya müşteri verisinin yetkisiz alıcıya gönderilmesi şüphesi bulunabilir.

İlk değerlendirmede şu noktalar önemlidir:

• Bulguyu ortaya çıkaran iletişim ve politika
• İnceleyicinin değerlendirme gerekçesi
• İlgili kişiler ve zaman aralığı
• Bilinen risk ve henüz açıklığa kavuşmamış sorular
• Ek inceleme veya veri koruma ihtiyacı

Her bulgu için dava dosyası açılması gerekmez. Bazı durumlar eğitim veya politika açıklamasıyla çözülebilir. Daha ciddi durumlarda ise Uyum, Hukuk veya Bilgi Güvenliği ekiplerinin değerlendirmesi gerekir.

1.2 Örneklemden Olay Kapsamına Geçiş

Supervisory Review kapsamında seçilen mesaj, olayın yalnızca bir bölümünü gösterebilir.

Örneğin, incelenen e-posta bir müşteri yazışmasının son mesajı olabilir. Önceki iletiler, ekler veya başka kanallardaki konuşmalar değerlendirme sonucunu değiştirebilir.

Bu nedenle:

İnceleme örneklemi, dava kapsamındaki bütün delillerin listesi olarak kabul edilmemelidir.

Olayın kapsamı belirlendikten sonra ilgili iletişimlerin ve belgelerin ayrıca araştırılması gerekir. Örnekleme, gözetim için kullanılan bir yöntemdir. Belirli bir uyuşmazlıkta gerekli verilerin bulunması ise farklı bir çalışma gerektirir.

2. Vaka Açılması ve İnceleme Kapsamının Belirlenmesi

Dava yönetiminde ilk kritik adım, olayın ne olduğunu ve hangi soruların araştırılacağını açıkça tanımlamaktır.

Kapsam belirsiz olduğunda gereksiz veri toplanabilir, önemli kayıtlar gözden kaçabilir veya inceleme farklı ekipler arasında dağılabilir.

2.1 Vaka Kaydında Bulunması Gereken Bilgiler

Kurumun vaka kayıt modeli aşağıdaki bilgileri içerebilir:

• Vaka numarası ve açılış tarihi
• Bulguyu bildiren kişi veya birim
• İlgili Supervisory Review politikası
• Başlangıç iletişiminin tanımlayıcı bilgileri
• İddia veya inceleme konusu
• İlgili kullanıcılar ve veri kaynakları
• İncelenecek tarih aralığı
• Vaka sahibi ve yetkili ekipler
• Koruma ve eskalasyon kararları

Bu kayıt, sürecin ortak referans noktasıdır. Teknik ekip mesaj kimlikleriyle çalışırken, hukuk ekibi olayın kapsamına, uyum ekibi ise ilgili politikalara odaklanabilir. Vaka numarası bu çalışmaların ilişkilendirilmesini kolaylaştırır.

2.2 İlgili Kişiler ve Veri Kaynakları

İnceleme kapsamındaki kişiler yalnızca mesajı gönderen çalışanla sınırlı olmayabilir.

Alıcılar, ilgili yöneticiler veya olayla bağlantılı başka çalışanlar da değerlendirmeye dahil olabilir.

Custodian, inceleme açısından ilgili verileri bulunduran veya kontrol eden kişi için kullanılan bir terimdir. Bir kişinin custodian olarak belirlenmesi, o kişinin ihlalden sorumlu bulunduğu anlamına gelmez.

Veri kaynakları ise olayın niteliğine göre değişebilir:

• Exchange posta kutuları ve arşivler
• Teams iletişimleri
• SharePoint ve OneDrive belgeleri
• Kurum içi dosya sistemleri
• Desteklenen üçüncü taraf iletişim arşivleri
• İnceleme kararları ve audit kayıtları

Hangi kaynağın hangi araçla incelenebileceği, kullanılan platformun desteğine ve kurumun erişim modeline bağlıdır.

2.3 Mini Senaryo — “Tek Mesaj, Eksik Bağlam”

Bir yatırım kuruluşunda reviewer, müşteriye gönderilen bir e-postada “bu işlemin getirisi kesindir” ifadesini fark eder.

İlk bakışta uygunsuz bir taahhüt şüphesi vardır. Ancak inceleme genişletildiğinde:

• Önceki mesajlarda hangi açıklamaların yapıldığı,
• İletiye hangi dokümanların eklendiği,
• İfadenin hangi ürün veya işlem için kullanıldığı,
• İlgili yöneticiyle başka bir yazışma bulunup bulunmadığı

araştırılır.

Bu senaryoda amaç, tek bir cümleden kesin sonuç çıkarmak yerine olayın bağlamını ortaya koymaktır.

Bu makaledeki mini senaryolar, süreçleri açıklamak amacıyla hazırlanmış örneklerdir.

3. Legal Hold ve Veri Koruma Stratejisi

Bir hukuki incelemede önemli risklerden biri, gerekli verilerin normal yaşam döngüsü içinde silinmesidir.

Kullanıcı mesajını silebilir, saklama politikası ilgili içeriği kaldırabilir veya bir uygulamanın işlem kayıtları süre sonunda erişilemez hale gelebilir.

Bu nedenle veri koruma ihtiyacı, incelemenin başlangıcında değerlendirilmelidir.

3.1 Retention ile Legal Hold Arasındaki Fark

Retention, verilerin normal saklama ve silme kurallarını yönetir.

Legal Hold, belirli bir hukuki ihtiyaç kapsamında ilgili verilerin korunmasını hedefler.

Mekanizma	Temel amacı	Dava yönetimindeki rolü
Retention Policy	Normal veri yaşam döngüsünü yönetmek	İlgili kayıtların belirlenen sürelerle saklanmasını desteklemek
Legal Hold / eDiscovery Hold	Belirlenen verileri korumak	İnceleme için gerekli içeriğin silinme riskini azaltmak
Arşivleme	Uzun süreli kayıt yönetimi ve erişim	Geçmiş iletişimlerin bulunmasına yardımcı olmak
Yedekleme	Kurtarma ihtiyacını karşılamak	Veri kaybı veya kesinti durumlarında kurtarmayı desteklemek

Bu mekanizmalar birlikte değerlendirilebilir. Ancak birinin bulunması, diğerlerinin bütün ihtiyaçlarını karşıladığı anlamına gelmez.

3.2 Koruma Kapsamı Nasıl Belirlenmeli?

Koruma kararında yalnızca kullanıcı listesi yeterli değildir.

Hangi veri kaynaklarının, hangi tarih aralığının ve gerekiyorsa hangi sorgu koşullarının kapsamda olduğu belirlenmelidir. Uygulamanın tamamlandığı ve ilgili konumlarda korumanın geçerli olduğu kontrol edilmelidir.

Özellikle şu ayrım önemlidir:

Mesajın korunması ile inceleme kararının ve audit kaydının korunması aynı kapsam olmayabilir.

Bir posta kutusundaki içeriği koruyan ayar, ayrı bir inceleme uygulamasının yorumlarını veya dışarı aktarılmış raporlarını otomatik olarak korumayabilir. Bu kayıtlar için ayrıca saklama yaklaşımı belirlenmelidir. Microsoft eDiscovery Hold belgeleri.

3.3 Mini Senaryo — “Mesaj Korundu, Karar Kayboldu”

Bir kurum, müşteri uyuşmazlığı nedeniyle ilgili posta kutularını koruma altına alır.

Daha sonra mesajlar bulunabilir. Ancak eski inceleme platformundaki reviewer yorumları ve eskalasyon geçmişi farklı bir saklama süresine tabi olduğu için erişilemez hale gelmiştir.

Sonuç olarak kurum:

• Mesajın içeriğini gösterebilir,
• Fakat daha önce nasıl değerlendirildiğini tam olarak açıklayamaz.

Sorunun kaynağı, koruma planının yalnızca iletişim içeriğini kapsamasıdır. İnceleme kayıtları da veri envanterine dahil edilmelidir.

4. eDiscovery ile Delil Toplama ve İnceleme

Supervisory Review bir bulguyu görünür hale getirebilir. eDiscovery ise ilgili elektronik verilerin belirli bir inceleme kapsamında bulunması ve değerlendirilmesine yardımcı olur.

Kullanılan çözüm ve lisans kapsamına göre arama, veri toplama, inceleme ve dışarı aktarma işlevleri değişebilir.

4.1 Delil Toplama Süreci

Delil toplamada temel sorular şunlardır:

• Hangi kişiler ve veri kaynakları kapsamda?
• Hangi tarih aralığı araştırılacak?
• Hangi arama koşulları kullanılacak?
• Mesaj ekleri ve bağlantılı belgeler gerekli mi?
• Toplanan veride eksik veya hatalı öğeler var mı?

Arama sonucunun bulunması, bütün ilgili verilerin bulunduğunu tek başına göstermez. Yanlış tarih aralığı, eksik kaynak veya fazla dar anahtar kelimeler önemli kayıtların gözden kaçmasına neden olabilir.

4.2 İnceleme Sonuçlarının Ayrılması

Toplanan veriler aynı anlamı taşımaz.

Bir belge olayla doğrudan ilgili olabilir. Başka bir belge yalnızca bağlam sağlayabilir. Bazı kayıtlar ise inceleme konusu dışında kalabilir.

Kurum, değerlendirme kategorilerini ve karar gerekçelerini açıkça tanımlamalıdır. “İlgili”, “ek inceleme gerekli” veya “kapsam dışı” gibi işaretlemelerin anlamı ekip içinde tutarlı olmalıdır.

İnceleme etiketi, hukuki kararın yerine geçmez. Teknik ve operasyonel sınıflandırmalar, hukuk ekibinin değerlendirmesine girdi sağlar.

4.3 Delil Paketi Hazırlanması

Hukuk veya yetkili denetim ekibine sunulacak pakette aşağıdaki bilgiler bulunabilir:

• İlgili iletişimler ve belgeler
• Gerekli ekler
• Kaynak ve tanımlayıcı bilgiler
• Arama kapsamı ve koşulları
• Toplama ve dışarı aktarma tarihleri
• Eksik veya işlenemeyen öğelere ilişkin açıklamalar
• İnceleme sonuçları ve ilgili işlem kayıtları

Ekran görüntüleri açıklamayı destekleyebilir. Ancak özgün içerik, ekler ve metadata gerektiğinde bunların yerine tek başına kullanılmamalıdır.

5. Delil Zinciri ve Denetim İzleri

Chain of Custody, verinin kaynağından inceleme ve paylaşım aşamalarına kadar geçirdiği işlemlerin izlenebilmesini ifade eder.

Dava yönetiminde yalnızca “bu mesaj elimizde” demek yeterli olmayabilir. Mesajın nereden alındığı, nasıl toplandığı ve kimlerin hangi işlemleri yaptığı da açıklanabilmelidir.

5.1 İzlenmesi Gereken İşlemler

Delil zincirinde aşağıdaki kayıtlar önem taşır:

• Veri kaynağı ve öğe kimliği
• Toplama zamanı ve kullanılan yöntem
• İşlemi gerçekleştiren kişi
• Dışarı aktarma bilgileri
• Dosyaların tutulduğu konum
• Erişim ve paylaşım işlemleri
• Yapılan dönüştürme veya redaksiyonlar

Dosya bütünlüğünü kontrol etmek için hash değerleri kullanılabilir. Ancak hash değerinin eşleşmesi, içeriğin doğru yorumlandığını veya hukuken kabul edilebilir olduğunu tek başına kanıtlamaz. Yalnızca karşılaştırılan dosyaların bütünlüğü hakkında bilgi sağlar.

5.2 Teknik Log ile İnceleme Kaydının Ayrılması

Exchange Message Tracking Log, mesajın teknik akışını araştırmaya yardımcı olur.

Reviewer’ın verdiği karar, yorum ve eskalasyon geçmişi ise farklı kayıtlardır.

Bu nedenle dava dosyasında:

Mesaj içeriği, teknik akış ve inceleme geçmişi birbiriyle ilişkilendirilmeli, ancak birbirinin yerine kullanılmamalıdır.

Zaman bilgileri de ortak bir çerçevede değerlendirilmelidir. Farklı sistemlerdeki saat dilimleri dikkate alınmadığında olay sırası yanlış yorumlanabilir.

6. Roller, Yetkilendirme ve Gizlilik

Dava yönetimi, serinin önceki bölümünde ele aldığımız RBAC ve minimum yetki yaklaşımını daha hassas bir kapsamda gündeme getirir.

Bir vaka içinde müşteri bilgileri, çalışan verileri, ticari sırlar veya hukuki değerlendirmeler bulunabilir. Bu nedenle erişim, görev ve vaka kapsamıyla ilişkilendirilmelidir.

6.1 Temel Roller

Rol	Temel sorumluluk
Reviewer	İlk bulguyu değerlendirmek ve gerekçesiyle aktarmak
Compliance Manager	Politika bağlamını ve uyum incelemesini yönetmek
Hukuk Ekibi	Hukuki kapsamı, koruma ihtiyacını ve paylaşım kararlarını değerlendirmek
eDiscovery / Teknik Ekip	Yetkili kapsamda veri arama, toplama ve dışarı aktarma işlemlerini yürütmek
Bilgi Güvenliği	Veri sızıntısı veya güvenlik olayı boyutunu araştırmak
Vaka Sahibi	Görevleri, süreleri ve kapanış koşullarını takip etmek

Bu roller işlevsel tanımlardır. Ürün izinleri ve kurum içi görev dağılımı ayrıca eşleştirilmelidir.

6.2 Kontrollü Paylaşım ve Redaksiyon

İlgili kayıtlar kurum dışına veya başka bir ekibe aktarılmadan önce paylaşım kapsamı belirlenmelidir.

Gereksiz kişisel bilgiler için redaksiyon uygulanabilir. Ancak redakte edilmiş çalışma kopyasıyla özgün kayıt arasındaki ilişki korunmalıdır.

Özgün verinin üzerine kontrolsüz değişiklik yapılması, daha sonra hangi içeriğin toplandığını açıklamayı zorlaştırabilir.

6.3 Çıkar Çatışması

İnceleyici olayın doğrudan tarafıysa veya değerlendirmeyi etkileyebilecek bir ilişkiye sahipse alternatif sorumlu belirlenmelidir.

Gerekli durumlarda ikinci inceleme uygulanabilir. Yeniden atamanın gerekçesi ve işlemleri kaydedilmelidir.

Bu kontrolün her platformda otomatik çalıştığı varsayılmamalıdır. Kurumun bağımsızlık politikası ve teknik yetkilendirme birlikte uygulanmalıdır.

7. Exchange On-Prem ve Microsoft Purview Yaklaşımı

Yerel Exchange ortamında dava yönetimi, mesaj kaynakları, arşiv sistemleri, denetim uygulamaları ve kurumun kullandığı diğer araçlarla birlikte tasarlanır.

Microsoft Purview tarafında ise Communication Compliance ve eDiscovery arasında bağlantılı işlevler bulunabilir. Ancak bu iki çözümün görevleri ayrı değerlendirilmelidir.

7.1 Communication Compliance Bulgusunun Araştırmaya Aktarılması

Communication Compliance içinde inceleyici, politika eşleşmesini değerlendirebilir ve ek inceleme için yönlendirebilir.

Microsoft’un belgelediği Escalate for investigation işlemi, seçilen mesajlardan bir eDiscovery araştırması başlatılmasını destekler. Bu işlemin yapılması, mesajın inceleme durumunu otomatik olarak kapatmaz. Microsoft inceleme ve eskalasyon belgeleri.

Bu bağlantı önemli bir kolaylık sağlar. Ancak açılan dosyanın kapsamı, koruma ihtiyacı ve araştırılacak diğer kaynaklar ayrıca değerlendirilmelidir.

7.2 Hibrit Ortamda Birleşik Vaka Kaydı

Hibrit bir kurumda ilgili veriler farklı konumlarda bulunabilir:

• Yerel Exchange posta kutusu
• Exchange Online posta kutusu
• Yerel arşiv
• Bulut belge kaynakları
• Ayrı inceleme uygulamasındaki karar kayıtları

Bir tarafta vaka açılması, diğer taraftaki bütün kaynakların otomatik dahil edildiği anlamına gelmez.

Birleşik vaka kaydı; kaynak konumlarını, sorumlu ekipleri ve elde edilen kayıtların ilişkisini göstermelidir. Böylece teknik ekiplerle hukuk ve uyum ekipleri aynı olay kapsamı üzerinden çalışabilir.

8. Sık Karşılaşılan Riskler ve Kaçınma Taktikleri

Dava yönetiminde sorunlar çoğu zaman tek bir teknik hatadan değil, süreçler arasındaki bağlantıların eksik olmasından kaynaklanır.

8.1 Eksik Kapsam

Risk: Yalnızca ilk işaretlenen mesajın incelenmesi.

Kaçınma taktiği: İlgili kişiler, tarih aralığı, iletişim dizileri ve veri kaynakları için kapsam haritası hazırlanması.

8.2 Geç Koruma Kararı

Risk: Gerekli verilerin normal saklama süreci içinde silinmesi.

Kaçınma taktiği: Koruma ihtiyacının erken değerlendirilmesi ve uygulamanın ilgili kaynaklarda doğrulanması.

8.3 Kayıt Türlerinin Karıştırılması

Risk: Mesaj içeriğinin korunmasıyla bütün audit geçmişinin de korunduğunun varsayılması.

Kaçınma taktiği: Mesaj, politika eşleşmesi, reviewer kararı ve teknik log için ayrı saklama kapsamlarının belirlenmesi.

8.4 Kontrolsüz Dışarı Aktarma

Risk: Dosyaların kişisel bilgisayarlarda veya belirsiz paylaşım alanlarında tutulması.

Kaçınma taktiği: Yetkili depolama konumları, erişim sınırları ve aktarım kayıtlarının kullanılması.

8.5 Erken Kapanış

Risk: İnceleme tamamlandığında bütün korumaların kaldırılması veya kayıtların silinmesi.

Kaçınma taktiği: Operasyonel kapanış, hukuki korumanın sona ermesi ve veri imhasının ayrı kararlar olarak yönetilmesi.

8.6 Mini Senaryo — “Dosya Kapandı, Koruma Devam Ediyor”

Bir müşteri uyuşmazlığında kurum içi değerlendirme tamamlanır ve operasyonel vaka kapatılır.

Ancak hukuk ekibi, uyuşmazlığın devam ettiğini ve ilgili kayıtların korunması gerektiğini bildirir.

Bu durumda reviewer’ın işi tamamlanmış olsa bile veri koruma süreci devam eder. Vakanın operasyonel kapanışı, Legal Hold’un kaldırılmasıyla aynı işlem değildir.

9. Sonuç ve Sonraki Adımlar

Bu makalede Exchange Server Supervisory Review Dava Yönetimi konusunu, ilk denetim bulgusundan kapsam belirlemeye, veri korumadan delil toplamaya ve kontrollü paylaşıma kadar ele aldık.

Gördüğümüz gibi:

• Supervisory Review bulgusu, daha kapsamlı bir araştırmanın başlangıcı olabilir.
• Örnekleme kapsamında seçilen iletişim, olayın bütün delillerini temsil etmez.
• Legal Hold ve saklama yaklaşımı, her veri kaynağının gerçek kapsamıyla değerlendirilmelidir.
• Mesaj içeriği, teknik loglar ve reviewer kararları ayrı kayıt türleridir.
• Delil zinciri, erişim kontrolleri ve açık sorumluluklar incelemenin güvenilirliğini destekler.

Dava yönetiminin başarısı, yalnızca e-postaların bulunmasına bağlı değildir. Bu verilerin hangi bağlamda toplandığı, nasıl korunduğu ve hangi süreçle değerlendirildiği de açıklanabilmelidir.

Serinin bir sonraki bölümünde Rakipler ve Pazar Durumu başlığı altında farklı iletişim gözetimi ve denetim çözümlerini ele alacağız. Kaynak kapsamı, inceleme iş akışları, delil yönetimi ve işletme maliyeti açısından hangi soruların sorulması gerektiğini değerlendireceğiz.