Exchange Server Supervisory Review Veri ve Denetim Boyutu

Exchange Server Supervisory Review’in teknik mimarisini, süreç yönetimini ve güvenlik boyutunu önceki bölümlerde ayrıntılı olarak ele aldık. Artık sıra, bu mekanizmanın “görünmeyen ama en kritik” kısmına geldi: veri ve denetim boyutu.

Her denetim süreci, aslında arkasında devasa bir veri ekosistemiyle çalışır. Hangi mesajın seçildiği, ne zaman incelendiği, hangi kararın verildiği ve bu kararların nasıl raporlandığı — tüm bu süreçler güvenilir veri yönetimi, loglama, ve ölçümleme temelleri üzerine kurulur.

Bu nedenle Supervisory Review’i yalnızca bir politika veya süreç olarak değil, aynı zamanda kurumsal veri denetim altyapısının bir parçası olarak değerlendirmek gerekir.

Bu yazı, sistemin “gözle görünmeyen ama izlenebilir” tarafını ortaya koyacak. Yani denetimin kanıt, rapor ve sürdürülebilirlik ayağını inceleyeceğiz ve veriyi saklama, ölçümleme, performans ve risk yönetimi arasındaki dengeyi inceleyeceğiz.

Exchange Server Supervisory Review Veri ve Denetim Boyutu makalesi içinde aşağıda ki başlıklara odaklanacağız.

1. Denetimin Görünmeyen Katmanı

Exchange Supervisory Review, yüzeyde yalnızca “e-posta inceleme ve politika kontrolü” gibi görünse de, arka planda oldukça karmaşık bir veri yaşam döngüsü barındırır. Bu yaşam döngüsü; mesajın denetime alınmasından, kararın verilmesine, logların tutulmasından, raporların oluşturulmasına kadar devam eden zincirleme bir yapıdır.

Bu zincirin her halkası doğru şekilde kayıt altına alınmadığında, denetimin güvenilirliği zedelenir. Bir kurumun uyum süreçlerinde “kanıt” sunabilme yeteneği, aslında bu görünmeyen veri katmanının sağlamlığına bağlıdır.
Bu yüzden bu bölüm, denetimin görünmeyen yüzünü — yani veri saklama, ölçümleme, izlenebilirlik ve performans yönetimi gibi konuları — görünür kılmayı hedefler.

Supervisory Review’i etkili kılan şey, yalnızca e-postaları tarayabilmesi değil; aynı zaman da hangi verinin, ne kadar süreyle, hangi koşullarda saklandığı ve nasıl raporlandığıdır. Bu boyut, Exchange Server ortamlarında regülasyon uyumunun sürdürülebilirliği açısından kritik önemdedir.

1.1 Veri Yaşam Döngüsü ve Denetim Zinciri

Denetim süreci, verinin sistemdeki yolculuğu boyunca izlenebilir olmasıyla anlam kazanır. Bir mesajın denetim sistemine girişiyle başlayan bu süreç; saklama, inceleme, raporlama ve arşivleme adımlarını içerir.

• Yakalama (Capture): Mesajın Transport Pipeline veya Journaling üzerinden denetim kapsamına alınması.
• İnceleme (Review): Politika motoru tarafından seçilen mesajların denetçiye aktarılması.
• Karar (Decision): Uygun/İhlal işaretlemesi ve denetim loglarının kaydı.
• Raporlama (Report): Denetim sonuçlarının yönetim ve regülatör sistemlerine aktarımı.
• Arşivleme (Archive): Denetim loglarının ve mesaj kayıtlarının Retention Policy veya Legal Hold kapsamında saklanması.

Bu zincirin her adımı, hem teknik izlenebilirliği (log’lar, audit kayıtları, raporlar) hem de yasal bütünlüğü (delil niteliği, veri koruma) temsil eder.

1.2 Denetim Verisinin Stratejik Rolü

Denetim verisi sadece geçmişin kaydı değildir; geleceğe dönük stratejik kararların da temelidir.

• Uyum (Compliance) süreçlerinde kanıt sağlar.
• Operasyonel denetimlerde risk alanlarını gösterir.
• Veri analitiği ve yapay zekâ tabanlı gözetim sistemleri için temel besleme kaynağıdır.

Kısacası, denetim verisi “geçmişin izini sürmek” için değil, aynı zamanda geleceğin politikalarını şekillendirmek için de kullanılır.

1.3 Bu Katmanın Önemi

Birçok kurumda denetim politikaları düzgün tanımlanmış olsa bile, bu politikaları destekleyen veri altyapısı zayıftır.
Verinin doğru yerde, doğru süreyle ve doğru biçimde saklanmaması; en gelişmiş Supervisory Review mimarisini bile uyumsuz hale getirebilir.

Bu nedenle Exchange Server ortamında denetimin görünmeyen katmanı şu üç ilkeye dayanır:

• İzlenebilirlik: Her eylemin, kim tarafından ve ne zaman yapıldığının bilinebilir olması.
• Değiştirilemezlik: Denetim kayıtlarının bütünlüğünün korunması (immutable storage).
• Erişilebilirlik: Gerektiğinde denetim kayıtlarının kolayca geriye dönük incelenebilmesi.

2. Veri Saklama, Retention ve Legal Hold ile İlişki

Exchange Supervisory Review yalnızca e-postaların anlık incelenmesiyle sınırlı değildir; denetimin değeri, bu incelemelerin ne kadar süreyle ve nasıl saklandığı ile doğrudan ilişkilidir.

Exchange Server mimarisinde bu alan, “Retention Policy”, “Litigation Hold” ve “Legal Hold” mekanizmalarının etkileşimiyle yönetilir.
Amaç, hem regülasyonların gerektirdiği süre boyunca verinin bütünlüğünü korumak, hem de uyum delillerini her an erişilebilir kılmaktır.

2.1 Saklama Politikaları (Retention Policy)

Exchange ortamında saklama politikaları, e-postaların sistemde ne kadar süreyle tutulacağını belirleyen kurallardır.
Supervisory Review kapsamında bu politikalar, denetime alınan iletilerin silinmeden önce belirli bir süre korunmasını sağlar.

Örneğin:

• Finans sektöründe regülasyon gereği e-posta kayıtları 7–10 yıl boyunca saklanmalıdır.
• Sağlık sektöründe HIPAA benzeri düzenlemeler, belirli hasta iletişimlerinin kalıcı olarak korunmasını zorunlu kılar.

Bu durumda Supervisory Review log’ları, Retention Policy ile uyumlu çalışarak inceleme sonuçlarının da belirli sürelerle korunmasını sağlar. Böylece, bir denetim sonucu “uygunsuz” işaretlense bile, o verinin ve karara ait kayıtların silinmesi mümkün olmaz.

Retention Policy yalnızca kullanıcı posta kutusuna değil, Supervisory Review’in log verilerine ve denetim kayıtlarına da uygulanmalıdır. Bu yapılandırma yapılmadığında, denetim süreci ileride “kanıt sunulamayan” bir duruma dönüşebilir.

2.2 Litigation Hold ve Legal Hold Etkileşimi

Litigation Hold, bir kullanıcı veya grup hakkında yasal soruşturma ya da regülasyon denetimi başlatıldığında devreye giren koruma mekanizmasıdır. Bu durumda ilgili posta kutularındaki tüm öğeler — silinmiş, değiştirilmiş veya taşınmış olsalar dahi — tamamen korunur.

Supervisory Review, Legal Hold durumunda özel bir davranış sergiler:

• İnceleme sonuçları ve log kayıtları da “yasal delil” statüsüne girer.
• Denetçi veya yönetici, bu kayıtları değiştiremez veya silemez.
• Raporlama modülü, “Legal Hold altında incelenen kayıtlar” için ayrı etiket oluşturur.

Bu durum özellikle finansal kurumlar ve kamu kuruluşları için hayati önem taşır; çünkü regülatörler sadece “mesajı” değil, “mesajın nasıl incelendiğini” de sorgular.

2.3 Arşivleme ve eDiscovery Bağlantısı

Exchange Server ve Microsoft Purview ortamlarında Supervisory Review verileri, arşiv posta kutularına ve eDiscovery sistemlerine entegre edilebilir. Bu sayede:

• İncelenen mesajlar, denetim log’ları ve sonuçlar birlikte arşivlenir.
• eDiscovery üzerinden geçmiş denetimler hızlıca sorgulanabilir.
• Denetim sonuçları doğrudan dava, inceleme veya iç soruşturma dosyalarına aktarılabilir.

Örnek Senaryo:
Bir finans kurumunda SPK denetimi başlatıldığında, Legal Hold devreye girer. Supervisory Review kayıtları otomatik olarak korunur, denetim sonuçları eDiscovery’ye aktarılır ve regülatör sadece mesaj içeriğini değil, mesajın kim tarafından, ne zaman, hangi kararla incelendiğini de görür. Bu kayıtlar, olası bir uyumsuzlukta kurumun “iyi niyetli denetim kanıtı” olarak kullanılır.

2.4 En İyi Uygulama Önerileri

• Denetim kayıtlarını ayrı bir Retention Tag ile koruyun. Supervisory Review sonuçları için özel bir Retention Label tanımlamak, delil bütünlüğünü artırır.
• Legal Hold durumunda manuel müdahaleyi kapatın. Denetçilerin veya yöneticilerin geçmiş kayıtları değiştirmesine izin vermeyin.
• Arşivleme ile yedeklemeyi karıştırmayın. Arşiv, uzun süreli saklama çözümüdür; backup (yedekleme) ise kurtarma mekanizmasıdır. Denetim bütünlüğü, yalnızca arşivleme katmanında korunur.
• Raporlama sürekliliği sağlayın. Legal Hold aktifken bile raporlama modülleri çalışmalıdır; sistemin “sessiz kalması” regülasyon ihlali olarak yorumlanabilir.

Sonuç olarak, Supervisory Review verilerinin saklama stratejisi, yalnızca bir IT kararı değil; uyum, hukuk ve risk yönetimi alanlarının ortak sorumluluğudur.

Mekanizma	Amacı	Denetim Üzerindeki Etkisi
Retention Policy / Retention Tag	E-posta ve denetim kayıtlarının belirli bir süre boyunca sistemde saklanmasını sağlar.	İncelenen iletilerin ve denetim sonuçlarının erken silinmesini engeller, delil bütünlüğünü korur.
Litigation Hold / Legal Hold	Yasal inceleme veya regülatör denetimi durumunda ilgili posta kutularındaki tüm öğeleri koruma altına alır.	Mesajların ve Supervisory Review log’larının değiştirilmesini veya silinmesini engeller; yasal delil niteliğini güçlendirir.
Arşivleme / eDiscovery	Geçmiş mesajlar, denetim kayıtları ve inceleme sonuçlarının aranabilir, raporlanabilir ve dosya bazlı incelenebilir olmasını sağlar.	Regülatör veya iç denetim taleplerinde, geçmiş denetim faaliyetlerinin hızlıca bulunmasını ve raporlanmasını mümkün kılar.

3. Ölçümleme ve Raporlama

Supervisory Review sürecinin yalnızca mesajları incelemesi değil, bunun çıktısını ölçülebilir, karşılaştırılabilir ve raporlanabilir hale getirmesi gerekir.
Bir kurum için gerçek değer, denetimin ne kadar “iyi yapıldığı” değil, bunun kanıtlanabilir olmasıdır.

Bu nedenle ölçümleme ve raporlama, Supervisory Review’in hem yönetişimsel hem de regülasyon tarafındaki en kritik aşamasıdır.

Regülatörler, kurumdan yalnızca “mesajları inceledik” demesini beklemez. Aynı zamanda şu soruların cevaplarını ölçülebilir şekilde talep eder:

• Ne kadar mesaj incelendi?
• Örnekleme oranı politikayla uyumlu mu?
• Kaç adet ihlal bulundu?
• Bu ihlaller ne kadar sürede ele alındı?
• Kim neyi inceledi?
• Denetim süreçleri aksamış mı?

İşte tüm bu soruların yanıtı, ölçümleme ve raporlama katmanında ortaya çıkar.

3.1 Denetim Metrikleri (Metrics)

Supervisory Review’de kullanılan metrikler, iki ana kategoriye ayrılır:

3.1.1 Operasyonel Metrikler

Denetim ekibinin performansını ölçer.

• İncelenen mesaj sayısı
• İhlal oranı (%)
• Reviewer başına iş yükü
• İhlal tespit süreleri (Time-to-Flag)
• Kuyrukta bekleme süresi
• Çözüm süresi (Resolution Time)

3.1.2 Regülasyon Metrikleri

Uyum süreçlerinin sürdürülebilirliğini ölçer.

• Politikaya uyum oranı (örnekleme %10 → gerçekleşen %9.7)
• Zorunlu inceleme SLAs (ör. 3 gün içinde denetleme)
• Legal Hold altında incelenen kayıt oranı
• İzlenebilirlik metrikleri (audit log bütünlüğü)

Bu metrikler sayesinde, kurum kendi iç denetimini “ölçülebilir bir sistem” haline getirir.

3.2 Raporlama Türleri

Supervisory Review raporları, hedef kitleye göre üç grup altında toplanır

3.2.1 Yönetim Raporları (Executive Reports)

• Özet KPI’lar
• Aylık ihlal trendleri
• Departman bazlı risk dağılımı
• Kritik ihlallerin yönetime yansıyan özeti

Yöneticilere “genel risk görünümünü” verir.

3.2.2 Operasyonel Raporlar

Denetim ekipleri için hazırlanır.

• Günlük / Haftalık denetim yükü
• Yoğunluk analizleri
• Reviewer bazlı performans
• Kuyruk optimizasyon raporları

Operasyonun sağlığı bu raporlarla takip edilir.

3.2.3 Regülasyon / Denetçi Raporları

SPK, KVKK, MASAK, FCA, SEC gibi otoritelerin beklediği rapor formatlarıdır.

Bu raporlar genellikle şunları içerir:

• Son 12–36 aylık denetim trendleri
• İhlal sınıflandırmaları
• Legal Hold kapsamındaki mesajlar
• Değiştirilemez audit log’ları
• Denetim zincirinin tam görünümü (chain of custody)

Bu raporların doğruluğu, bir regülatör incelemesinde kurumun kaderini belirleyebilir.

3.2.4 Exchange On-Prem vs Purview Raporlama Farkları

Exchange Server on-prem ortamında raporlama çoğunlukla şu yöntemlerle yapılır:

• PowerShell
• Message Tracking Log
• ECP Supervisory Review Panel (sınırlı görünürlük)
• Export-CSV tabanlı raporlar

Exchange Online ortamındaysa Purview Communication Compliance araçları kullanılır ve raporlama çoğunlukla şu yöntemlerle yapılır:

• AI tabanlı ihlal sınıflandırması
• Hazır dashboard’lar
• Trend grafikleri
• Otomatik regülatör uyum paketleri
• Detaylı eskalasyon grafikleri

Raporlama araçları Log Analytics / SIEM Entegrasyonu ile bütünleştirilmeli ve böylece ihlal trendleri otomatik olarak analiz edilir. Raporlama araçları için

• Sentinel
• Splunk
• Elastic

kullanılabilir ve bu ek araçlar ihlal trendleri otomatik olarak analiz edilir.

3.5 Mini Senaryo — “İhlal Artışı Alarmı”

Bir portföy yönetim şirketinde aylık Supervisory Review raporu incelenir. Normalde ihlal oranı %3 seviyesindedir. Ancak son ay raporunda oran %9.5 olarak görünmektedir.

Yapılan analizde:

• Aynı departmanda çalışan iki yeni personelin
• Finansal analiz belgelerini yanlış etiketlemesi
• Ve bu belgeleri dış e-posta yoluyla paylaşması nedeniyle ihlaller patlamıştır.

Bu rapor sayesinde:

• Ek eğitim planlanır,
• Etiketleme politikasında iyileştirme yapılır,
• Risk komitesine uyarı gönderilir.

Ölçümleme olmadan bu sorun asla fark edilmezdi.

• 4. Riskler, Sınırlamalar ve Kaçınma Taktikleri
• 5. Ölçeklenebilirlik ve Performans Dikkatleri

Ölçümleme ve raporlama, Supervisory Review’in sadece “operasyonel” değil, aynı zamanda stratejik bir araç olmasını sağlar. Böylece kurum;

• Riskleri erken tespit eder
• Departman bazlı kırmızı bayrakları izler
• Regülasyon denetimlerine hazırlıklı olur
• Süreçlerini sürekli geliştirir

Kısacası; Gözetimi yönetilebilir, kanıtlanabilir ve sürdürülebilir hale getirir.

4. Riskler, Sınırlamalar ve Kaçınma Taktikleri

Supervisory Review, doğru kurulduğunda kurumsal uyumu güçlendiren kritik bir güvenlik ve denetim mekanizmasıdır. Ancak doğru yapılandırılmadığında veya izlenmediğinde, kurum için yeni riskler yaratabilir.
Bu bölümde, Exchange Server ortamlarında en sık karşılaşılan tehlikeleri, sınırlamaları ve bunlara karşı uygulanabilecek önleyici stratejileri ele alıyoruz.

Bu riskler genellikle dört ana başlık altında toplanır:

• Teknik riskler (log şişmesi, performans yükü, örnekleme hataları)
• Operasyonel riskler (eksik denetim, yanlış etiketleme, kuyruk birikmesi)
• Veri bütünlüğü riskleri (silinen loglar, eksik denetim zinciri, bozuk arşivler)
• Uyum riskleri (regülasyon ihlali, yetersiz raporlama, değiştirilebilir loglar)

Aşağıda bu risklerin ana kategorilerini ve kaçınma taktiklerini detaylandırıyoruz.

4.1 Yanlış veya Tutarsız Örnekleme (Sampling Riskleri)

Supervisory Review’in en kritik parçası örnekleme oranıdır. Yanlış örnekleme, tüm denetim sürecinin güvenilirliğini zedeler.

4.1.1 Olası Riskler

• Örnekleme oranının politikanın altına düşmesi (%10 yerine %6 gibi)
• Rastgele örneklemenin tutarsız çalışması (aynı kişiden çok fazla örnek, bazı kişilerden hiç üretilmemesi)
• Transport Rule / Journaling gecikmeleri nedeniyle kaçan mesajlar
• Yetki hataları nedeniyle bazı mailbox’ların dahil edilmemesi

4.1.2 Kaçınma Taktikleri

• Günlük/haftalık örnekleme doğrulama raporları
• “Sampling drift” tespiti (oran kaymalarının grafikle izlenmesi)
• Uyarı mekanizmaları: örn. “Sampling oranı politika limitinin %2 altına düştüğünde alert üret”
• Transport Rule + Journaling kombinasyonunu kullanmak (tek kaynaktan beslenen örnekleme sistemleri her zaman risklidir)

4.2 Veri ve Log Şişmesi (Data Growth Risks)

Denetim sistemlerinin en büyük problemi, zamanla kontrolsüz büyüyen log ve arşiv verileridir.

4.2.1 Olası Riskler

• Denetim log’larının MB yerine GB’lara ulaşması
• MessageTracking log rotasyonunun yanlış yapılandırılması
• Arşiv mailbox’ların dolması
• Depolama maliyetlerinin gereksiz artması
• Indexing hizmetinin aşırı yüklenmesi (ContentIndex yükü)

4.2.2 Kaçınma Taktikleri

• Log rotasyon politikalarını sıkılaştırmak
  (ör. 30 gün → 14 gün)
• Archiving + Retention Tag kullanmak
• Supervisory Review log’ları için ayrı bir mailbox/DB kullanmak
• Indexing yükü kontrolü için DAG içinde ContentIndex dengelemesi

💡 İpucu:
Büyük kurumlarda log retention süresinin yanlış ayarlanması, regülasyon cezasına neden olan ilk sıradaki hatadır.

4.3 Denetim Zincirinin Bozulması (Chain of Custody Riskleri)

Regülatörler açısından en hassas konu budur: “Verinin orijinal hali ile sunulan deliller birebir aynı mı?”

4.3.1 Olası Riskler

• Denetim log’larının manuel olarak silinmesi
• Reviewer’ın yaptığı işaretlemelerin kaybolması
• Legal Hold devreye alınmadan veri değişikliği yapılması
• Yedekleme ve arşiv sistemleri arasında tutarsızlık

4.3.2 Kaçınma Taktikleri

• Immutable mailbox audit log’ları etkinleştirmek
• Legal Hold + Retention Tag kombinasyonu
• Denetim sonuçlarını SIEM (Sentinel, Splunk, Elastic) ile dış ortama aktarmak
• Supervisor işaretlemelerinin otomatik olarak ayrı bir arşivde tutulması

4.4 Operasyonel Hatalar (Human & Process Risks)

Teknoloji mükemmel olabilir; ancak hatalı süreç tasarımları veya personel hataları denetimi etkisiz kılabilir.

4.4.1 Olası Riskler

• Reviewer kaçakları (bazı kullanıcıların mesajları hiç incelenmemesi)
• Yanlış atanmış roller (Reviewer’ın kendi yöneticisini incelemesi)
• İnceleme kuyruğunda biriken binlerce mesaj
• Manual-export CSV hataları (tarihsiz kayıtlar, eksik alanlar)

4.4.2 Kaçınma Taktikleri

• Otomatik kuyruk temizleme politikaları
• Çatışma önleme (Conflict Detection) kuralları
• Reviewer performans raporları
• Otomatik eskalasyon mekanizması

4.5 Mini Senaryo — “Geciken Denetim Felaketi”

Bir finans kuruluşunda Supervisory Review politikası %10 örnekleme üzerine kuruludur. Ancak sistem yöneticisi, Message Tracking log rotasyonunu yanlış yapılandırmıştır:

• Log retention: 5 gün
• Denetçiler raporu: aylık

Bu durumun fark edilmesi 2 ay sürer. Sonuç: Regülatör incelemesi sırasında 40 günlük denetim verisi eksik çıkar. Bu yalnızca uyum ihlali değil, aynı zamanda ciddi bir cezai yaptırım riskine dönüşür.

Sorunun kaynağı: Veri saklama ve log yönetimi, operasyonel süreçle senkronize edilmemişti. Bu senaryo, veri ve denetim boyutundaki risklerin gerçek hayatta nasıl büyüyebileceğini somut bir şekilde gösterir.

Bu bölümde ele alınan riskler — özellikle örnekleme tutarsızlıkları, log şişmesi ve audit zinciri bozulması — Supervisory Review’in en kritik zafiyet noktalarıdır. Doğru yapılandırma, düzenli takip ve otomasyon sayesinde bu riskler minimize edilir ve sistem hem teknik olarak hem de regülasyon açısından sağlam bir zemine oturur.

5. Ölçeklenebilirlik ve Performans Dikkatleri

Supervisory Review’in başarısı yalnızca doğru politikalar veya güvenli bir yetkilendirme modeliyle sınırlı değildir. Büyük organizasyonlarda gerçek zorluk, artan e-posta hacmini, log yükünü ve inceleme trafiğini sürdürülebilir performansla yönetebilmektir.

Bir kurumda yüzlerce değil, binlerce mailbox varsa; günlük trafiğin on binlerce mesajı bulduğu yapılar söz konusuysa; denetim kuyrukları, index’ler ve raporlama motoru doğru tasarlanmadığında sistem hızla tıkanabilir. Bu nedenle Supervisory Review mimarisi, özellikle yüksek ölçekli ortamlarda performans ve kaynak yönetimi açısından özel dikkat gerektirir.

5.1 Büyük Ölçekli Ortamlarda Veri Hacmi Yönetimi

10.000+ mailbox bulunan kurumlarda günlük e-posta trafiği kolayca 1–3 milyon mesaja ulaşabilir. Bu durum, denetim sisteminin aşağıdaki yükleri taşımasını gerektirir:

• Transport Pipeline log hacmi
• Message Tracking log büyümesi
• Denetim kuyruğuna düşen mesaj sayısı
• Indexing işlemleri
• Arşiv posta kutularının boyut artışı

5.1.1 Dikkat Edilmesi Gereken Noktalar

• Supervisory Review örnekleme oranı yüksek tutulduğunda (ör. %20) log hacmi katlanarak artar.
• Arşiv mailbox’lar hızla büyüyebilir; Retention Tag yanlış yapılandırılmışsa sistem tıkanabilir.
• Dag içindeki pasif kopyalardaki ContentIndex yükü bile denetimi etkiler.

💡 Öneri:
Sadece örnekleme oranını değil, kaç kullanıcı / hangi departman / günlük trafik parametrelerini birlikte değerlendirerek kapasite planlaması yapılmalıdır.

5.2 Performans Optimizasyonu: Indexing ve Kuyruk Yönetimi

Supervisory Review’in en fazla CPU ve Disk IO tüketen bileşeni Content Indexing’dir.
Denetim kuyruğuna alınan her mesaj için:

• İçerik parse edilir
• Metadata çıkarılır
• Risk filtreleri uygulanır
• İnceleme kuyruğuna eklenir

Bu işlemler yoğun disk ve CPU yükü oluşturur.

5.2.1 Performans İçin Öneriler

• Mailbox Database’leri küçük ve dengeli tutun (250–500 GB önerilir).
• Content Index arızalarını düzenli kontrol edin (Search Foundation sorunları).
• Denetim kuyruklarını pasif bir mailbox’a taşımayın.
• Yüksek IOPS gerektiren denetim mailbox’ları SSD tier üzerinde tutulmalıdır.

💡 Pratik İpucu:
Çok yoğun ortamlarda Supervisory Review için dedike bir mailbox database oluşturmak en iyi uygulamalardandır.

5.3 Paralel İşleme ve Otomasyon

Denetim sürecini hızlandırmak için paralel işlem stratejileri kullanılır.

5.3.1 Nelere Dikkat Edilmeli?

• Çok sayıda Reviewer olduğunda iş yükü dengesi önemlidir.
• Otomatik görev dağıtımı (auto-assign) açık bırakılmalı.
• İnceleme kuyruğu dolduğunda sistem otomatik uyarı üretmelidir.
• PowerShell veya API ile periyodik istatistik toplayıp “kuyruk yoğunluk grafiği” oluşturulmalıdır.

5.3.2 Otomasyonun Sağladığı Avantajlar

• Kuyruk birikmeden yük devretme
• Yoğun departmanlarda ekstra sampling uygulama
• Performans dar boğazlarını otomatik tespit etme
• Regülatör raporları için otomatik export üretebilme

5.4 Exchange On-Prem vs Purview: Performans Karşılaştırması

5.4.1 On-Prem Supervisory Review:

• Donanım kaynaklarına bağımlıdır
• Performans logların yoğunluğundan etkilenir
• Indexing ve Transport Pipeline yükü çok daha fazladır

5.4.2 Purview Communication Compliance:

• Microsoft altyapısında otomatik ölçeklenir
• Denetim işleri otomatik yük dağılımıyla işlenir
• Çok büyük hacimler için daha kararlı sonuç verir
• AI ile risk sınıflandırması yapılır

Bu nedenle özellikle büyük kurumlar, uzun vadede on-prem denetimi Purview’a taşımayı tercih etmektedir.

5.5 Mini Senaryo — “20.000 Mailbox Ortamında Denetim Çökme Eşiği”

Büyük bir bankada günlük trafik 2.4 milyon mesajdır. Supervisory Review politikası %10 örnekleme ile çalışmaktadır → 240.000 mesaj denetime adaydır.

Yanlış yapılandırılan senaryoda:

• Tüm denetim sonuçları tek bir mailbox’a yönlendirilir
• Bu mailbox 1 ayda 480 GB boyuta ulaşır
• Content Index sürekli “Crawling / Failed” durumuna girer
• Denetim kuyruğu 40.000+ mesaja çıkar
• Reviewer paneli açılmaz hale gelir

Sonuç:
Kurumsal denetim 2 hafta boyunca fiilen durur. Bu durum SPK kontrolünde yöneticilere ciddi bir risk raporu olarak döner.

Çözüm ise şudur:

• Denetim verilerinin farklı DB’lere dağıtılması
• Kademeli örnekleme
• Otomatik arşiv politikalarının devreye alınması

Bu senaryo bize Supervisory Review performansının yalnızca teknik değil, uyum açısından da kritik olduğunu gösterir.

Ölçeklenebilirlik ve performans göz ardı edildiğinde, en iyi politikalar bile doğru çalışmaz.
Bu nedenle:

• Denetim hacmi planlanmalı,
• Log yükü kontrol edilmeli,
• Kuyruk yönetimi optimize edilmeli,
• Büyük ortamlarda paralel işleme stratejileri kullanılmalı