Exchange Supervisory Review Microsoft Purview Geçiş Stratejileri

Exchange Supervisory Review Microsoft Purview Geçiş Stratejileri makalemiz daha önce paylaşmış olduğumuz Exchange Server Supervisory Review Hibrit ve Karşılaştırma makalemizin devamı niteliğindedir.

Paylaşmış olduğumuz Exchange Server Supervisory Review Hibrit ve Karşılaştırma makalemiz de hibrit yapılarda denetimin nasıl kırılgan hale geldiğini, mail akışının iki farklı sistem arasında parçalanmasının hangi uyum risklerine yol açtığını ve modern regülasyon beklentilerinin artık yalnızca e-posta üzerinden çalışan on-prem teknolojilerle karşılanamayacağını detaylı olarak ele aldık ve bu noktada kurumların önünde büyüyen kaçınılmaz bir soruyu sorduk

“Mevcut denetim altyapımızı nasıl daha güvenli, daha görünür, daha bütünsel bir modele taşıyabiliriz?”

Cevap çok net Microsoft Purview Communication Compliance ’a geçiş yaparak büyüyen soru ve sorunları çözebiliriz. Ancak bu geçiş yalnızca teknik bir migration değildir; aynı zamanda:

• kurumun denetim kültürünü,
• politika modelini,
• regülasyonla uyum paradigmasını,
• veri akışını,
• iş akışlarını
• ve risk yönetim yöntemlerinin değiştirilmesidir ve köklü şekilde yeniden şekillendiren çok katmanlı bir dönüşüm sürecidir.

Bu makalede, Purview’a geçişin tüm stratejik yönlerini; teknik gereksinimlerden operasyonel zorluklara, regulasyon uyumundan en iyi pratiklere kadar çok boyutlu bir şekilde inceliyoruz. Amaç yalnızca bir geçiş rehberi sunmak değil; kurumun gelecekteki denetim modeli için sağlam bir vizyon oluşturmak.

1. Purview ’a Geçiş Artık Neden Zorunlu Hale Geldi?

Günümüzde kurumsal iletişim yalnızca e-posta trafiğinden ibaret değil; Teams mesajları, OneDrive dosya paylaşımları, mobil istemciler ve çoklu iş uygulamaları iletişim ekosisteminin temel parçaları haline geldi. Exchange Server’ın geleneksel Supervisory Review modeli ise bu karmaşık yapıyı kapsamakta yetersiz kalıyor. On-prem altyapıların sınırlı raporlama yetenekleri, yapay zekâ desteğinden yoksun olmaları, log yönetiminin giderek zorlaşması ve regülasyonların çok daha geniş kapsamlı denetim talep etmesi nedeniyle kurumların daha gelişmiş bir çözüme geçmesi kaçınılmaz hale geliyor.

Bu makalenin odağı, mevcut Supervisory Review altyapısını risksiz, kontrollü ve görünürlük kaybı olmadan Microsoft Purview Communication Compliance’a taşımanın en doğru yollarını ortaya koymaktır. Çünkü çağdaş bir denetim modeli yalnızca e-postaları değil; tüm dijital iletişimi kapsamalı, ihlalleri yapay zekâ destekli analizlerle öngörebilmeli ve uyum gerekliliklerini sürdürülebilir biçimde garanti altına almalıdır.

2. Purview ’a Geçiş Geçiş Modelinin belirlenmesi

Purview Communication Compliance’a geçiş, yalnızca teknik bir taşıma işlemi değildir; kurumun denetim kültürünü, politika mimarisini ve risk yönetim yaklaşımını doğrudan yeniden şekillendiren stratejik bir dönüşümdür. Bu nedenle ilk adım, kuruma en uygun geçiş modelinin belirlenmesidir. Her organizasyonun mevcut altyapısı, kullanıcı dağılımı, regülasyon kapsamı ve operasyonel olgunluğu farklıdır; dolayısıyla uygulanacak geçiş yöntemi de tek tip olamaz.

Bazı kurumlar hızlı ve tek aşamalı bir geçişle “big-bang” yaklaşımını tercih ederken, bazıları riskleri minimize etmek için kademeli pilot modelleri veya hibrit-sürekli stratejileri benimser. Doğru modeli seçmek, geçişin güvenli, kesintisiz ve denetim boşluğu oluşturmadan ilerlemesi için kritik önemdedir.

Şimdi Purview’a geçiş için kullanılabilecek üç temel yaklaşımı detaylı olarak inceleyelim.

2.1 Tek Aşamalı Tam Geçiş

Big-Bang modeli, tüm Supervisory Review denetim süreçlerinin, politikalarının ve kullanıcı kapsamının tek seferde, planlı bir kesinti penceresi içerisinde Microsoft Purview Communication Compliance’a taşındığı tam kapsamlı geçiş yaklaşımıdır. Bu yöntem özellikle olgunlaşmış bulut kullanımı olan, mail flow’un büyük ölçüde Exchange Online üzerinden yürüdüğü ve on-prem altyapıyı artık operasyonel olarak sürdürmek istemeyen kurumlar tarafından tercih edilir.

Bu yaklaşımın en önemli avantajı, denetim modelinin tek seferde sadeleşmesi ve eski on-prem bileşenlerle yeni Purview politikaları arasında geçici uyumsuzluk yaşanmamasıdır. Ancak hızlı ilerlemesi, geçiş öncesi hazırlık aşamasının titizlik gerektirmesine yol açar.

2.1.1 Tek Aşamalı Tam Geçiş Ne Zaman Uygun?

Kullanıcıların %90’ı zaten Exchange Online’da ise Denetim kapsamındaki trafiğin büyük kısmı zaten cloud üzerinden akıyorsa, on-prem Supervisory Review’i sürdürmek gereksiz bir operasyon yükü oluşturur.

On-prem denetim altyapısı eski, yorgun veya hataya açık hale geldiyse Transport kuralları, journaling zinciri, audit log retention süreleri veya SR politikaları artık modası geçmiş yöntemlerle çalışıyorsa, onları yamalamak yerine doğrudan modern mimariye geçmek daha az risklidir.

Regülasyon Purview kullanımını destekliyorsa FINRA, SEC, FCA, KVKK veya MAS gibi otoriteler, Purview Communication Compliance’ı kurumsal gözetim için kabul etmektedir. Denetim otoritesinin “cloud-first” yaklaşımı desteklediği durumlarda Big-Bang geçiş kritik avantaj sağlar.

2.1.2 Tek Aşamalı Tam Geçiş Avantajları

• Big-Bang yaklaşımının avantajları, tüm Supervisory Review sürecini tek bir pencerede Purview’a taşıdığı için geçiş süresini en aza indirir. Aylar sürecek kademeli bir geçiş yerine, kontrollü bir kesinti ile tek aşamada tamamlanabilir.
• Denetim süreçlerinin tek yerde birleşmesi ile Eski on-prem politikalar ve yeni cloud politikaları arasında çakışma yaşanmaz. Tüm denetim kararları, audit kayıtları ve raporlamalar Purview altında birleşir; bu da operasyonu ciddi ölçüde sadeleştirir.
• Yanlış politika atanma riskinin azalması Kademeli geçişlerde sık görülen “eski SR politikası aktif kaldı → cloud politikası devreye girmedi” gibi karışıklıklar bu yöntemde yaşanmaz.
  Tüm politikalar eş zamanlı devre dışı/aktif edilir.

2.1.3 Tek Aşamalı Tam Geçiş Dezavantajları

• Kısa sürede ciddi test gerektirmesi gerekmektedir. Tek geçiş penceresi olduğu için shadow policy testleri, mail flow testleri, keyword dictionary doğrulaması, örnekleme oranları gibi tüm unsurlar geçiş öncesinde yoğun biçimde doğrulanmalıdır.
• Denetim boşluğu oluşmaması için sıkı validasyon ihtiyacı Transport rule yönlendirmeleri, journaling kapatma/açma zamanlaması, SR policy disable zamanı ve Purview policy enable zamanı milisaniyelik hassasiyetle planlanmalıdır. Aksi durumda bazı iletiler hiç denetlenmeyebilir.

Avantajları	Dezavantajları
✔ En hızlı geçiş modelidir ✔ Denetim süreçleri tek yerde birleşir → sade yapı sağlar ✔ Yanlış politika atanma riski azalır	✖ Kısa sürede kapsamlı test gerektirir ✖ Geçiş sırasında denetim boşluğu oluşmaması için yoğun validasyon gerekir

Tek aşamalı tam geçiş senaryolarında Denetim boşluğunun oluşmaması için yoğun doğrulama şarttır ve bu modelde en kritik risk: “Geçiş penceresinde hiçbir mesajın denetim dışı kalmaması.” gerekmektedir. Bu nedenle geçiş öncesi:

• Transport rule aktarımları
• Journaling’in kapatılması/yeniden yönlendirilmesi
• On-prem SR policy disable zamanlaması
• Purview policy enable zamanlaması
• Log retention kesintisinin olmaması

gibi adımlar milisaniye hassasiyetle planlanmalıdır.

2.2 Kademeli Geçiş

Kademeli geçiş modeli, Supervisory Review denetim süreçlerini adım adım Microsoft Purview’a taşıyan kontrollü bir yaklaşımdır. Genellikle yüksek regülasyon baskısı altında çalışan, geniş kullanıcı tabanına sahip kurumlarda uygulanan bu yöntem, riskleri minimize ederken aynı zamanda mevcut operasyonu kesintiye uğratmaz.

Purview politikaları önce küçük bir pilot grupta test edilir, ardından belirli departmanlara genişletilir ve son aşamada tüm organizasyon kapsamına alınır. Bu model, özellikle karmaşık mail flow yapıları, çok departmanlı organizasyonlar veya hassas kullanıcı grupları için en güvenli yöntem olarak tercih edilir.

2.2.1 Kademeli Geçiş Ne Zaman Uygun?

Aşağıdaki koşullardan biri veya birkaçı mevcutsa bu model en doğru seçimdir:

• Kullanıcı tabanı geniş ve heterojense (Örneğin: operasyon, satış, trader, hukuk, portföy yönetimi gibi farklı risk profilleri olan ekipler)
• Mail flow veya SR politikaları çok karmaşık bir yapıda ise Tek seferde geçiş riskli olabilir; yapı taşlarını sırayla Purview’a taşımak gerekir.
• Regülasyon gereği denetim boşluğu oluşmaması kritikse Finans sektöründe kademeli geçiş çoğu zaman zorunludur.
• IT ekipleri küçük, operasyon yoğun veya değişim yönetimi zor ise Kurumun değişim kapasitesi Big-Bang’e uygun olmayabilir.

2.2.2 Kademeli Geçiş Avantajları?

• Daha düşük risk → Her aşamada validasyon yapılır, hatalar küçük ölçekli kalır.
• Pilot grup ile sağlıklı test imkânı → Politika davranışı, örnekleme oranları ve anahtar kelime setleri gerçek ortamda doğrulanır.
• Departman bazlı kontrollü yayılım → Yüksek riskli gruplar önce alınabilir.
• Kültürel adaptasyon kolaylaşır → Uyum ve denetim ekipleri yeni sürece kademeli olarak alışır.

2.2.3 Kademeli Geçiş Dezavantajları?

• Çift denetim modeli geçici olarak devam eder (On-prem + Purview politikaları bir süre paralel çalışır)
• Politika çakışması riskleri artar Yanlış departmana eski politikanın uygulanması gibi hatalar olabilir.
• Geçiş süresi uzar Pilot → departman → geniş kapsam → tüm organizasyon gibi bir yol haritası zaman alır.
• İletilerin nerede denetlendiğinin takibi zorlaşabilir Özellikle hibrit mail flow üzerinde.

Avantajları	Dezavantajları
✔ Düşük riskli ve kontrollü ilerleme imkânı ✔ Pilot grup üzerinden gerçek ortam testleri ✔ Departman bazlı yayılım ile kontrollü geçiş ✔ Kültürel / operasyonel adaptasyonu kolaylaştırır	✖ Bir süre çift denetim modeli sürer ✖ Politika çakışması riski artar ✖ Geçiş süresi uzar ✖ Denetim akışının nerede gerçekleştiğini takip zorlaşabilir

Kademeli geçişte aşağıdaki teknik detaylar hayati önem taşımaktadır.

• Shadow policy (pasif politika) ile davranış doğrulama yapılmalıdır.
• Denetim boşluğu oluşmaması için on-prem SR policy disable zamanı ile Purview policy enable zamanı çakıştırılmalıdır.
• Departmanlara geçiş yapılırken risk profili yüksek gruplar önce alınmalıdır (finans, yatırım, yönetim kurulu vb.).
• Denetim raporlarında çift kaynak (on-prem + cloud) karmaşası oluşmaması için geçici raporlama filtreleri uygulanmalıdır.
• Mail flow, geçiş süresince tutarlı route üzerinde çalışmalıdır.

2.3 Hibrit-Sürekli Model (Hybrid Permanent)

Hibrit-sürekli geçiş modeli, Supervisory Review denetim yapısını tek bir tarihte veya lineer bir departman sıralamasıyla taşımak yerine; Exchange On-prem Supervisory Review ve Exchange Online Purview denetiminin bir süre paralel çalıştığı, denetim kapsamının ise sürekli genişletildiği esnek bir yaklaşımdır.

Exchange Purview hybrid modelinde ki amaç;

• Kritik denetim süreçlerinin bir anda kırılmaması,
• Denetim kültürünün aşamalı olarak modernleştirilmesi,
• Uyum ekiplerinin yeni Purview iş akışına kademeli fakat sürekli olarak adapte edilmesidir.

Hibrit-sürekli model, değişken iş yükleri, karmaşık mail akışları veya uzun vadeli transformasyon planı olan kurumlarda pratik bir çözümdür.

2.3.1 Hibrit-Sürekli Model Ne Zaman Uygun?

Hibrit-Sürekli Model yaklaşımı aşağıda ki durumlarda tercih edilmelidir.

• Denetim kapsamı çok genişse Tüm kullanıcıları aynı anda taşımak riskli, uzun ve operasyonel açıdan zor olabilir.
• Kurumda kritik roller hâlâ on-prem kullanıyorsa Örneğin yönetim, portföy ekipleri, hukuk veya risk grupları hâlâ on-prem Exchange kullanıyorsa denetimin tamamen cloud’a kaydırılması zaman alabilir.
• Birden fazla regülasyon türüne uyumlu denetim gerekiyorsa Bazı regulasyonlar cloud tabanlı denetimi kabul ederken, bazıları on-prem log erişimi gerektirebilir.
• Mail flow yapısı karmaşıksa ve tüm route’lar tek seferde değiştirilemiyorsa Hybrid Coexistence + Compliance Routing senaryoları için bu model idealdir.
• Uzun süreli bir transformasyon planı varsa Tamamen Purview’a geçiş planı 6–18 ay gibi bir takvime yayılıyorsa hibrit-sürekli model önerilir.

2.3.2 Hibrit-Sürekli Model Avantajları

• Az riskli ve esnek bir yapıdır Denetim genişlemesi aşamalı yapılır; kesinti ve hata riski azalır.
• Eski ve yeni denetim sistemleri paralel çalışabilir Böylece kullanıcı geçişleri sırasında boşluk oluşmaz.
• Operasyon ekipleri üzerinde baskı azalır Değişim yönetimi daha kontrollüdür.
• Regülasyon gereksinimleri farklı olan gruplar ayrı yönetilebilir Örneğin bazı gruplar cloud, bazı gruplar on-prem denetlenebilir.

2.3.3 Hibrit-Sürekli Model Dezavantajları

• En uzun geçiş süresi bu modeldedir Aşamalı büyüme nedeniyle toplam süre Big-Bang ve Kademeli modele göre daha uzundur.
• Denetim ve raporlamada karmaşıklık yaşanabilir Hem Purview hem on-prem SR logları aynı süreçte izlenir.
• Politika çakışması riski en yüksek modellerdendir Aynı kullanıcıya çifte politika uygulanması mümkündür.
• Mail flow karmaşası oluşabilir Özellikle “kim Purview ile denetleniyor, kim SR ile?” sorusu zaman zaman karışabilir.

Avantajları	Dezavantajları
✔ Daha düşük risk – Esnek ilerleme ✔ On-prem ve Purview denetimin paralel çalışabilmesi ✔ Operasyonel baskıyı azaltır ✔ Farklı regülasyon gereksinimlerini aynı anda yönetebilir	✖ En uzun süreli geçiş modelidir ✖ Denetim ve raporlama karmaşıklığı oluşabilir ✖ Politika çakışması riski yüksektir ✖ Hibrit mail flow yönetimi zorlaşabilir

Hibrit-sürekli model teknik olarak en dikkatli planlanması gereken yaklaşımdır:

• Geçiş boyunca on-prem ve Purview log retention süreleri uyumlu tutulmalıdır.
• Denetim sonuçları için çift kaynaklı raporlama konsolidasyonu yapılmalıdır.
• Pilot grupların ilerlemesi KPI tabanlı olmalıdır (ör. false-positive oranı, escalation yoğunluğu).
• Mail routingte split routing + compliance routing karma mimarisi kullanılabilir.
• Politika çakışmaları için policy precedence tasarımı yapılmalıdır.
• Her genişleme aşamasında “denetim boşluğu testi” uygulanmalıdır.

2.3.4 Purview Communication Compliance’a geçiş değerlendirme

Purview Communication Compliance’a geçiş için kullanılabilecek üç temel yaklaşım bulunmaktadır. Aşağıdaki tablo, bu modelleri hız, risk, gereksinimler ve operasyonel karmaşıklık açısından karşılaştırır. Böylece hangi modelin kurumunuza daha uygun olduğunu hızlıca değerlendirebilirsiniz.

Tek Aşamalı Tam Geçiş (Big-Bang)	Kademeli Geçiş (Pilot → Departman)	Hibrit-Sürekli Geçiş Modeli
✔ En hızlı geçiş modeli ✔ Tüm denetim tek yerde birleşir ✔ Riskli politika çakışması azalır✖ Kısa sürede yoğun test gerektirir ✖ Geçiş sırasında denetim boşluğu riski	✔ En güvenli ve kontrollü yöntem ✔ Pilot gruplarla gerçek ortam testleri ✔ Departman bazlı yayılım✖ En uzun ikinci modeldir ✖ Süreç boyunca on-prem + Purview paralel çalışır	✔ En esnek ve düşük riskli model ✔ On-prem & Purview aynı anda kullanılabilir ✔ Regülasyon çeşitliliği olan kurumlar için ideal✖ En uzun toplam geçiş süresi ✖ Denetim ve raporlama karmaşası yaratabilir
Ne zaman uygun? • %90+ kullanıcı Exchange Online’da • On-prem SR yorgun/karmaşık • Regülasyon cloud uyumlu	Ne zaman uygun? • Büyük/karmaşık organizasyonlar • Farklı departman risk profilleri • Değişim yönetimi kritikse	Ne zaman uygun? • Yönetim/özel roller on-prem ise • Hybrid mail flow değiştirilemiyorsa • 12+ aylık transformasyon planı varsa
Öne çıkan risk: • Millisaniyelik yanlış zamanlama = denetim boşluğu	Öne çıkan risk: • Eski ve yeni politikaların çakışması	Öne çıkan risk: • Denetim kaynaklarının (on-prem + cloud) karışması

Her geçiş modeli farklı bir operasyonel ve regülasyonel ihtiyaca karşılık verir:

• Big-Bang → en hızlı, en sade; ancak en hazırlık yoğun model
• Kademeli Geçiş → en kontrollü, en güvenli; ancak daha uzun
• Hibrit-Sürekli Model → en esnek; ancak operasyonel karmaşıklığı en yüksek yöntemdir

Doğru model, kurumun mevcut yapısı, regülasyon kapsamı, mail flow mimarisi ve dönüşüm takvimi dikkate alınarak belirlenmelidir.

3. Denetim Boşluklarını Engelleme Stratejileri

Purview’a geçişte en kritik risk, bir iletinin — geçiş sırasında veya hibrit aşamada — hiçbir denetim mekanizmasına takılmadan sistemden geçmesi durumudur. Bu durum “audit gap” olarak adlandırılır ve özellikle finans, portföy yönetimi, yatırım danışmanlığı ve hukuk gibi regülasyon yoğun sektörlerde kurumsal uyum açısından en ciddi zafiyetlerden biri olarak kabul edilir.

Denetim boşluklarının oluşması çoğu zaman sistemsel hatadan değil; yanlış zamanlama, çakışan politikalar, hibrit mail flow, eksik kullanıcı eşleşmesi veya log retention kesintisinden kaynaklanır. Bu bölümde geçiş sürecinde denetim boşluğu oluşmasını tamamen engellemek için uygulanması gereken en kritik stratejileri derinlemesine ele alıyoruz.

3.1 Mail Flow Standardizasyonu (Cloud-First Routing)

Geçiş sırasında mail flow’un tutarsız olması, denetim boşluklarının en sık rastlanan nedenidir. Bir kullanıcının mail’i:

• bazen on-prem SR tarafından,
• bazen Purview tarafından,
• bazen hiçbir sistem tarafından denetlenmeyebilir.

Çözüm olarak Geçiş başlamadan tüm outbound mail’ler tek bir route üzerinden akmalıdır ve en güvenli yöntem Cloud-first routing modelidir. Tüm mail’ler Purview’dan geçer ve böylece Denetim kaçakları sıfırlanır. Hybrid ortamda Transport Rule + Connector eşleşmelerinin tekilleştirilmesi önerilmektedir.

Ana kural “Hangi kullanıcı nerede olursa olsun, önce Purview’dan geçsin.” yaklaşımıdır.  Bu tek karar bile denetim boşluklarını %90 azaltır.

3.2 Politika Geçişinde Shadow-Mode Kullanımı

Shadow mode, Purview politikasının aktif olmadan, sadece pasif gözlem yaparak çalıştığı moddur. Gölge yöntem olarakda adlandırabiliriz Bu yöntem ile örnekleme oranını, keyword davranışlarını, içerik sınıflandırmayı, politikaların yanlış kullanıcıya uygulanmasını test edebilmekteyiz.

Gölge yöntem geçiş sırasında: yanlış kullanıcı eşleşmesini, beklenmeyen yüksek örnekleme yükünü, hatalı keyword tetiklemelerini önceden yakalamaya yardımcı olur. Purview geçiş de Shadow Mode seçiöi sıfır riskli geçişin temelini oluşturmaktadır.

3.3 Denetim Kapsamı Haritalama (Who → Where → How Analizi)

Geçişte en sık yapılan hata “Hangi kullanıcının hangi sistem tarafından denetlendiği net değil.” Bu nedenle geçiş öncesi yapılması gereken en kritik çalışma denetim kapsamı haritalamasıdır. Haritalamada üç basit ama önemli soru vardır:

• Who → Kim denetlenecek? Departman, kullanıcı grubu, risk seviyesi.
• Where → Nerede denetlenecek? On-prem SR mi? Purview mu?
• How → Nasıl denetlenecek? Örnekleme mi? Keyword mü? ML/AI mi?

Bu harita çıkarılmadan yapılan tüm geçiş işlemleri yüksek risk içermektedir.

3.4 Log Kesinti Riskini Engelleme (Retention Gap Prevention)

Denetim boşluklarının en tehlikelisi log tarafında ortaya çıkandır. Şu durumlar bu açık kabul edilemez risk üretir:

• Journaling geçişi sırasında gecikme
• Purview policy enable/disable zamanlama hatası
• Transport Rules geçişinde kesinti
• On-prem log retention’ın erken silinmesi
• Purview’da indexing gecikmesi

Log Kesinti Riskini Engellemek için

• On-prem journaling hiçbir zaman Purview aktif edilmeden kapatılmamalıdır.
• Indexing gecikmeleri için Purview’da “Signal latency reports” kullanılmalıdır.
• Geçiş gününde log retention süreleri çift taraflı artırılmalıdır (ör. 14 → 30 gün).
• Purview policy enable/disable zamanı milisaniye hassasiyetiyle eşleştirilmelidir.

3.5 Uyum Dostu Geçiş Penceresi (Compliance-Driven Cutover)

Regülasyon yoğun sektörlerde “geçiş penceresi” teknik ekip tarafından değil, uyum birimi tarafından belirlenmelidir. Uyum ekipleri geçiş penceresinde şunları ister:

• Denetlenmeyen mesaj olmamalı
• Kritik kullanıcı trafiği düşük olmalı
• Finansal kapanış/dönem sonu olmamalı
• Yönetim kurulu iletişimi yoğun olmamalı

Uyum birimi tarafından genellikle kabul gören yöntemler düşük hacim saatleri (21:00–23:00 arası) olarak bilinen iş yükünün daha az ve mesai saati sonrası işlemlerin yapılmasıdır. Gerekirse bu geçiş yapılmadan önce e-posta alt yapısı geçici süre durdurulmalı (mailflow) ve sonrasında geçiş başlatılmalıdır. Bu yöntem ile iletiler geç gitse bile denetlenmeyen ileti olmayacaktır.

3.6 Test ve Değerlendirme Süreci

Purview’a geçişte test süreci “e-posta gönder → çalışıyor mu?” seviyesinden çok daha fazlasıdır. Aşağıdaki test seti mutlak suretle uygulanmalıdır ve bu değerlendirme setleri kuruma  ve bağlı bulunduğu uyum yasalarına göre hazırlanmalıdır.

• Shadow-policy davranış testi
• Erişim kontrolü ve RBAC denetimi
• Keyword dictionary doğrulaması
• Risk skorlaması (AI/ML) davranış testi
• Purview → Case Creation → Escalation tam zincir testi
• On-prem + Purview log senkronizasyon testi
• Denetim boşluğu testi (Audit Gap Simulation)

Bu değerlendirme testlerine Audit Gap Simulation ları da eklenmelidir.

• 10 farklı içerik tipi
• 5 farklı gönderen/alıcı modeli
• 5 farklı lokasyon senaryosu
• 3 farklı örnekleme oranı gibi simülasyonlar değerlendirme testleri içinde bulunmalıdır.

Denetim boşlukları Purview geçişinin en kritik riskidir. Bu riskleri ortadan kaldırmak için:

• Mail flow standardizasyonu
• Shadow-mode testleri
• Denetim kapsamı haritalaması
• Log kesinti koruması
• Uyum dostu geçiş penceresi

• Validasyon süitleri kesinlikle uygulanmalıdır.

4. Geçiş Öncesi Denetim Envanteri (Audit Inventory)

Purview Communication Compliance’a geçiş başlamadan önce, mevcut Supervisory Review altyapısının tüm bileşenlerini eksiksiz şekilde görmek gerekir. Bu çalışma, yalnızca teknik bir envanter değil; aynı zamanda kurumun bugün hangi veriyi, hangi politika ile, hangi kullanıcı için, nerede ve ne kadar süreyle denetlediğini ortaya çıkaran stratejik bir analizdir.

Audit Inventory aşaması, geçiş sırasında olası denetim boşluklarını, politika çakışmalarını, log kesintilerini ve yanlış kullanıcı kapsamlarını daha başlamadan ortadan kaldırır. Başarılı bir Purview geçişinin temeli bu aşamada atılır.

Bu bölümde, geçiş öncesi mutlaka çıkarılması gereken tüm bileşenleri detaylı şekilde ele alıyoruz.

4.1 Mevcut SR Politikalarının Envanteri

Geçiş öncesinde tüm Supervisory Review politikalarının detaylı şekilde çıkarılması gerekir:

• Denetlenen kullanıcı/AD grupları
• Örnekleme oranları (5%, 10%, 20% vb.)
• Anahtar kelime setleri
• Yakalama türü (keyword → sampling → sentiment vb.)
• Politikanın neden uygulandığı (regülasyon, iç yönerge, operasyonel gereklilik)
• İstisnalar (excluded users/groups)

Bu liste, Purview tarafındaki yeni politikaların birebir doğru eşleştirilmesini sağlar.

4.2 Transport, Journaling ve Capture Mekanizmaları

Mevcut iletilerin hangi mekanizma ile denetlendiğinin bilinmesi geçişte kritik bir gereksinimdir:

• Transport Rule bazlı denetim
• Journaling mailbox / external journal system
• Keyword-based capture
• Conditional routing

Bu bilgiler olmadan Purview’da doğru denetim kapsamı kurulamaz.

Not:
Birçok kurumda transport + journaling + SR politika kombinasyonları yıllar içinde karmaşık hale gelmiştir. Purview geçişi bu karmaşıklığı temizlemek için en doğru fırsattır.

4.3 İnceleme Kuyrukları ve Bekleyen Mesajlar

Geçiş sırasında on-prem SR’de bekleyen mesajlar göz ardı edilmemelidir:

• SR Review Queue boyutu
• Bekleyen incelemelerin adedi
• Açık denetçi iş yükü
• “Needs Review” durumda bekleyen mesajlar
• Kapanmamış vakalar

Bu mesajların Purview tarafında kaybolmaması için geçiş sıralamasına dahil edilmelidir.

4.4 Legal Hold ve Retention Politikaları

Denetim, saklama politikalarından tamamen bağımsız değildir. Bu nedenle geçiş öncesi şu bilgiler çıkarılmalıdır:

• Hangi kullanıcılar Legal Hold altında?
• Hangi retention tag’leri uygulanıyor?
• On-prem mailbox retention süreleri
• Purview/Exchange Online retention durumları
• Çift yönlü journaling retention süreçleri
• Third-party archive entegrasyonu (Mimecast, Veritas Enterprise Vault vb.)

Bu envanter, log kesinti riski ve denetim boşluğu ihtimalini ciddi ölçüde azaltır.

4.5 Denetim Rolleri ve Yetkilendirme Yapısı

Purview’a geçişte roller değişeceği için, önce mevcut yapının çıkarılması gerekir:

• Reviewer’lar kim?
• Uyum ekibinin yetki seti?
• Yönetici denetimi var mı?
• Security Admin hangi erişimlere sahip?
• RBAC rol dağılımı nasıl?
• Çatışma önleme mekanizmaları aktif mi?

Bu bilgiler olmadan Purview’da doğru case management yapılandırması yapılamaz.

4.6 Yönetici Posta Kutularının Konumu

Bu madde çok kritik ve çoğu kurum tarafından gözden kaçırılır:

• Yönetim kadrosu hâlâ on-prem’de mi?
• VIP/CEO trafiği nereye route ediliyor?
• Hybrid mailbox senaryosu var mı?
• Shared mailbox denetim kapsamı belirlenmiş mi?

Yönetici trafiğinin doğru yönlendirilmemesi, geçmişte audit gap oluşmasının en büyük sebeplerinden biridir.

4.7 Log Süreleri ve Log Akışları

Geçiş öncesi logların nasıl tutulduğunun bilinmesi Purview entegrasyonunun temelidir:

• On-prem message tracking log retention
• SR audit log retention
• Journaling retention
• SIEM entegrasyonu (Splunk, Sentinel vb.)
• Purview sinyal işleme (signal latency)

Log süreleri uyumsuz olursa, geçiş sırasında ciddi uyum riski oluşabilir.

4.8 Uyum Dokümantasyonu ve Politika Gerekçeleri

Regülasyon uyumluluğu için:

• Denetim politikasının yazılı gerekçesi
• İç yönergeler
• Uyum komitesi onayları
• ISO 27001 / SOX / FINRA kayıtları
• Dış denetçi raporları hazırlanmalıdır.

Purview için yeni politika tasarlanırken bu dokümanlar yol haritanın temelini oluşturur

Geçiş öncesi Audit Inventory çalışması bir teknik analizden çok daha fazlasıdır. Bu aşama tamamlanmadan:

• doğru politika eşleştirmesi yapılamaz,
• denetim boşlukları tespit edilemez,
• log kesintileri fark edilemez,
• rol dağılımı optimize edilemez,
• geçiş modeli doğru seçilemez.

Bu nedenle Purview’a geçişin en kritik aşaması, Audit Inventory’nin eksiksiz tamamlanmasıdır.

5. Purview’da Karşılığı Olan / Olmayan Özellikler

Purview Communication Compliance, klasik Exchange Supervisory Review’in yerini alan modern gözetim modelidir. Ancak bu dönüşüm “birebir aynı özelliklerin yeni platformda devam etmesi” şeklinde değildir. Purview bazı eski mekanizmaları tamamen değiştirmiş, bazılarını genişletmiş, bazılarını ise artık farklı teknolojilerle karşılar hale gelmiştir.

Bu nedenle Purview’a geçiş sürecinde en kritik adımlardan biri, mevcut on-prem SR özelliklerinin Purview tarafındaki karşılıklarının doğru şekilde eşleştirilmesidir. Bu bölümde hem birebir karşılıkları hem Purview’ın sunduğu yeni yetenekleri hem de artık kullanılmayan eski SR mekanizmalarını ele alıyoruz.

Aşağıdaki tablo, klasik Exchange Supervisory Review özellikleri ile Microsoft Purview Communication Compliance’ın yeteneklerini yan yana göstererek hangi fonksiyonların birebir taşındığını, hangilerinin modernleştirildiğini ve hangilerinin artık kullanılmadığını özetlemektedir.

Ortak Yetenekler	Purview’ın Ek / Modern Yetenekleri	Purview’da Olmayan Yetenekler
✔ Örnekleme (Sampling) ✔ Keyword-based içerik yakalama ✔ Reviewer ataması ✔ Eskalasyon akışları ✔ Denetim kararları (Uygun / İhlal / İnceleme Gerekli) ✔ Temel raporlama fonksiyonları	✔ Yapay zekâ destekli ihlal tespiti (AI/ML) ✔ Teams / OneDrive / SharePoint denetimi ✔ Davranış ve iç tehdit analitiği ✔ Case Management (tam entegre vaka yönetimi) ✔ Real-time alerting ✔ Power BI & SIEM entegrasyonu ✔ Çok kanallı gözetim (multichannel supervision)	✖ Transport Rule tabanlı SR denetimi ✖ Journaling tabanlı SR yakalama modeli ✖ Klasik SR Review Queue arayüzü ✖ Tek politika – tek kuyruk monolitik yapı ✖ Sadece e-posta sınırına bağlı denetim ✖ On-prem içerik sınıflandırma eksikliği

Bu karşılaştırma gösteriyor ki Purview, yalnızca SR’in bulut versiyonu değil; çok daha geniş kapsamlı, yapay zekâ destekli, çok kanallı modern bir gözetim çözümüdür. Purview’a geçiş, eski SR özelliklerini taşımak kadar, kurumun gelecekteki denetim yaklaşımını yeniden tasarlaması anlamına gelir.

6. Geçiş Riskleri ve Çözüm Önerileri

Purview Communication Compliance’a geçiş yalnızca teknik bir taşıma işleminden ibaret değildir; aynı zamanda kurumun tüm denetim altyapısının yeniden yapılandırıldığı, ciddi risk barındıran bir dönüşüm sürecidir.

Bu dönüşüm sırasında yapılacak en küçük hata bile mesajların hiç denetlenmemesine, log zincirinin kırılmasına, regülasyon uyumsuzluğuna veya kritik bir yöneticinin trafiğinin görünmez hâle gelmesine yol açabilir.

Bu bölüm, Purview geçişinde kurumların en sık karşılaştığı riskleri ve bunları engellemek için uygulanması gereken en etkili yöntemleri kapsamaktadır.

6.1 Denetim Boşluğu Riski (Audit Gap)

6.1.1. Risk Nedir?

Geçiş sırasında bir e-postanın ne on-prem SR, ne de Purview tarafından denetlenmeden sistemden geçmesidir. Bu durum:

• FINRA/SEC/ECB denetimlerinde büyük uyumsuzluk yaratır
• CEO/CFO trafiğinde ciddi risk oluşturur
• Davranışsal ihlallerin tespit edilememesine yol açar

6.1.2 Neden Oluşur?

• Politikaların disable/enable zamanlamasının çakışması
• Journal → Purview kapatma/açma aralığındaki gecikme
• Hybrid mail flow yönlendirme hatası
• Routing’in Purview’a ulaşmadan on-prem’e düşmesi

6.1.3 Çözüm Önerileri

• Cloud-first routing uygulanmalı
• Purview politikaları önce shadow-mode’da test edilmeli
• On-prem SR kapatılmadan önce Purview %100 aktif olmalı
• Log retention süresi geçiş öncesi 30 güne çıkarılmalı
• Denetim boşluğu simülasyon testleri yapılmalı

6.2 Yanlış politika kapsamı riski

6.2.1 Risk Nedir?

Bir kullanıcının yanlış politikaya dahil edilmesi:

• Gereksiz yere yüksek örnekleme yükü yaratabilir
• Yönetici/VIP kullanıcıların hiç denetlenmemesine yol açabilir
• Hatalı eskalasyon süreçleri tetikleyebilir

6.2.2 Neden Oluşur?

• AD grup eşleşme hataları
• Dynamic group senkronizasyon gecikmeleri
• SR politikalarının eski kullanıcı gruplarına bağlı kalması
• Purview policy mapping yanlış yapılması

6.2.3 Çözüm Önerileri

• Kullanıcı kapsamı için Who → Where → How haritası çıkarılmalı
• Dynamic group yerine security group kullanımı tercih edilmeli
• VIP yöneticiler için ayrı “high-risk review policy” açılmalı
• Purview’daki kullanıcı kapsamı shadow-mode ile doğrulanmalı

6.3 Log retention uyumsuzluğu

6.3.1 Risk Nedir?

Geçiş sırasında log retention sürelerinin uyumsuz olması:

• Bazı mesajların trace edilememesine
• Denetim zincirinin kopmasına
• SIEM/Sentinel entegrasyonlarının bozulmasına
• Regülasyon problemlerine yol açar.

6.3.2 Neden Oluşur?

• On-prem message tracking log süresinin kısa olması
• SR audit loglarının erken silinmesi
• Journaling retention süresinin Purview ile uyuşmaması
• Signal latency’nin Purview’da geç işlem görmesi

6.3.3 Çözüm Önerileri

• Geçişten önce tüm log retention süreleri uyumlu hale getirilmeli
• On-prem → minimum 14–30 gün retention
• Purview signal latency monitör edilmeli
• SIEM log ingestion sırasında boşluk testleri yapılmalı

6.4 Dava Yönetim zorlukları

6.4.1 Risk Nedir?

On-prem SR’nin basit inceleme ekranına alışkın ekiplerin Purview Case Management modelinde:

• Eskalasyon
• Disposition workflow
• Multi-stage review
• Alert triage

adımlarını öğrenmekte zorlanması. Bu durum: İncelemelerin gecikmesine ve ihlallerin geç değerlendirilmesine yol açabilir.

6.4.2 Neden Oluşur?

• Tamamen yeni bir case yönetimi mantığı
• Reviewer rollerinin değişmesi
• Çok aşamalı workflow’a alışamama

6.4.3 Çözüm Önerileri

• Reviewer’lar için 2 haftalık pilot eğitim ortamı
• “Low-risk pilot” kullanıcılarla gerçek denetim denemesi
• Eskalasyon zincirinin önceden belirlenmesi
• Uyum ekibi için “Case Playbook” hazırlanması

6.5 Teams/OneDrive görünmezliği

6.5.1 Risk Nedir?

On-prem SR sadece e-posta denetler. Eğer kurum hibrit geçişte Teams / OneDrive / SharePoint trafiğini Purview’a dahil etmezse:

• İç tehdit eylemleri
• Varlık sızıntıları
• Uygunsuz davranışlar
• Yanlış bilgi paylaşımı tamamen görünmez hâle gelir.

6.5.2 Neden Oluşur?

• Purview politikalarının yalnızca Exchange’e uygulanması
• Teams/OneDrive sinyallerinin aktif edilmemesi
• Chat/Share aktivitelerinin denetim kapsamına yanlış dahil edilmesi

6.5.3 Çözüm Önerileri

• Multichannel denetim mutlaka aktif edilmeli
• Teams, OneDrive, SharePoint sinyalleri Purview’a bağlanmalı
• İç tehdit sinyalleri (Insider Risk) cross-check yapılmalı
• Chat tabanlı ihlaller için AI/ML modelleri açılmalı

Bu risklerin tamamı doğru planlama, shadow-mode testleri, mail flow standardizasyonu ve kullanıcı kapsamı haritalaması ile tamamen kontrol altına alınabilir.

7. Purview Geçişi İçin En İyi Pratikler (Best Practices)

Purview Communication Compliance’a geçiş, yalnızca bir “teknoloji taşıma” süreci değildir; aslında kurumsal denetim modelinin baştan sona yeniden tasarlanmasıdır. Bu nedenle geçiş sürecinin her adımının hem teknik hem de yönetişim açısından titizlikle planlanması gerekir.

Aşağıdaki en iyi pratikler, yüzlerce geçiş senaryosunda tekrarlanan sorunların önüne geçmek ve denetim boşluğu oluşmadan Purview’a sorunsuz bir şekilde geçiş yapabilmek için geliştirilen stratejilerdir.

7.1 Politika Migrasyonu (Policy Mapping & Alignment)

Purview tarafına geçmeden önce mevcut Supervisory Review politikalarının Kapsamı, Örnekleme oranları, Risk seviyeleri, Eskalasyon gereksinimleri, Departmansal farklılıkları tek tek çıkarılmalıdır. Exchange SP ‘den Exchange Online Purview Communication Compliance’a En iyi geçiş yöntemleri için;

• On-prem politikalar birebir taşınmamalı; Purview’un çok kanallı yapısına göre yeniden tasarlanmalıdır.
• VIP yöneticiler için ayrı bir High-Risk Policy oluşturulmalıdır.
• Regulation-driven (FINRA/SEC/SOX/BTK) politikalar Purview’da “template” bazlı hazırlanmalıdır.
• Mevcut SR politikaları purview shadow-mode’da test edilmelidir.

7.2 Mail Flow Standardizasyonu

Denetim boşluklarının %70’i geçişten çok routing hatalarından kaynaklanır. Mail trafiğinde oluşturulan birden fazla Connector, tekilleştirilmeyen bağlayıcılar geçiş sırasında ciddi riskleri barındırmaktadır. Exchange SP ‘den Exchange Online Purview Communication Compliance’a En iyi geçiş yöntemleri için;

• Cloud-first routing uygulanmalıdır.  Yöneticilerin gönderdiği tüm e-postalar O365 üzerinden route edilmelidir.
• Transport rules yeniden düzenlenmeli; çakışan kurallar kaldırılmalıdır.
• Hybrid Connector üzerinde message-type bazlı ayrımlar test edilmelidir.
• Journal rule → Purview geçişinde overlap (örtüşme) süresi tanımlanmalıdır.

7.3 Log Retention Eşitleme

Log retention süreleri farklı olduğunda:

• SR logu var → Purview logu yok
• Purview logu var → transport logu yok
• Case management logları incomplete gibi kritik problemler yaşanır.

Exchange SP ‘den Exchange Online Purview Communication Compliance’a En iyi geçiş yöntemleri için;

• SR log retention → minimum 30 gün
• Purview signal latency testleri yapılmalı
• SIEM/Sentinel’e giden loglar çift yönlü doğrulanmalı
• On-prem message tracking log süreleri arttırılmalı
• Legal Hold / retention policies geçiş öncesi entegre edilmelidir.

7.4 Üst Yönetim Öncelikli Geçiş (Executive-First Strategy)

Geçişin en kritik kısmı “kim önce taşınacak?” sorusudur. Uyum ve denetim açısından ilk taşınması gereken grup: üst yönetim / kritik personel olması beklenmektedir. Çünkü bu kullanıcıların kullanmış olduğu özellikler hem daha zengindir hem de iletileri en kritiktir. Üst yönetim her zaman için iyi bir pilot geçis envanteridir ama riski de büyüktür. Biraz, azcık bir şey kumar oynamak gerekebilir bu tür geçişlerde :)

Üst Yönetimş Öncelikli Geçiş kullanmak bir takım avantajlara da neden olmaktadır.  Bu kullanıcılar En yüksek regülasyon riski yöneticilerdedir. Denetlenmeyen VIP e-postaları finansal ceza doğurabilir ve Purview AI modelleri en çok yöneticilerin davranışsal trafiğinde anlam kazanır.

Exchange SP ‘den Exchange Online Purview Communication Compliance’a En iyi geçiş yöntemleri için;

• CEO, CFO, Risk, Hukuk ve Trading ekipleri pilot lider grup olmalıdır.
• VIP routing kuralları Purview’a taşınmadan SR kapatılmamalıdır.
• Purview policy kapsamı bu gruplar üzerinde doğrulanmalıdır.

7.5 Eğitim ve Pilot Grup Yönetimi

Purview Case Management ve AI/ML tabanlı denetim mekanizmaları, on-prem SR’deki basit yapıya alışmış ekipler için zorlayıcı olabilir. Exchange SP ‘den Exchange Online Purview Communication Compliance’a En iyi geçiş yöntemleri için;

• Reviewer’lara yönelik 5 günlük eğitim seti: UI, alerts, case yönetimi, disposition process, audit trail
• 1 aylık pilot denetim dönemi
• Case eskalasyon zincirinin pilot ekip üzerinde test edilmesi
• Eğitim sonrası pratik: “Simüle edilmiş ihlal olayları”

7.6 Doğrulama/Değerlendirme Senaryoları

Geçişin en kritik aşaması doğrulama (validation) safhasıdır. Test edilmesi gereken senaryolar;

• Bir mesaj hem on-prem hem Purview tarafından yakalanıyor mu?
• Sadece Purview’a ulaşması gereken mesajlar doğru sınıflanıyor mu?
• VIP yöneticiler Purview dashboard’unda görünür mü?
• Teams / OneDrive ihlalleri tetikleniyor mu?
• Eskalasyon zinciri doğru kişilere ulaşıyor mu?

Exchange SP ‘den Exchange Online Purview Communication Compliance’a En iyi geçiş yöntemleri için;

• 20+ senaryoluk validation matrix hazırlanmalıdır.
• Her senaryo için pass/fail ve log kanıtı saklanmalıdır.

7.7 Geçişten Sonra Doğrulama (Post-Migration Validation)

Geçiş tamamlandıktan sonra en az 2 hafta boyunca hem Purview hem de mail flow üzerinden görünürlük doğrulanmalıdır. Exchange SP ‘den Exchange Online Purview Communication Compliance’a En iyi geçiş yöntemleri için;

• Daily monitoring dashboard kurulmalı
• Policy coverage listesi her sabah otomatik üretilmeli
• Case completion rate takip edilmeli
• SIEM integration health raporlanmalı
• Inactive signals incelenmelidir

Microsoft Purview Communication Compliance’a geçiş, yalnızca teknik bir migrasyon değildir; denetim kültürünün, politika yapısının ve kurum içi yönetişim süreçlerinin yeniden şekillenmesi anlamına gelir. Bu nedenle geçiş planı hazırlanırken yalnızca “mevcut Supervisory Review ayarlarını taşımak” değil, modern bir denetim mimarisini baştan tasarlamak gerekir.

8. Gerçek Hayattan Geçiş Örnekleri ve Senaryolar

Purview Communication Compliance’a geçiş, çoğu kurum için yalnızca teknik bir dönüşüm değil; aynı zamanda süreçlerin, politikaların ve denetim kültürünün yeniden şekillenmesidir. Bu aşamada yapılan küçük bir hata bile ciddi denetim boşluklarına, regülasyon uyumsuzluğuna ve yönetişim zafiyetlerine yol açabilir.

Aşağıdaki mini senaryolar, gerçek dünyada karşılaşılan tipik sorunları ve bunlara yönelik çözüm yaklaşımlarını özetlemektedir.

8.1 Eksik Politika Kapsamı ve VIP Kullanıcılar Denetim Dışında Kaldı

Bir finans kurumunda geçiş planı yapılırken mevcut on-prem Supervisory Review politikaları, “tüm çalışanları” kapsadığı düşünülerek Purview’a birebir taşındı. Ancak Purview politikaları departman bazlı oluşturulurken üst yönetim (CEO, CFO, Risk Direktörü) ilgili gruplara eklenmedi.

Başlık	Açıklama
Sonuç	VIP kullanıcıların e-posta trafiği uzun süre Purview tarafından hiç denetlenmedi ve en yüksek risk grubu görünmez hâle geldi.
Kök Neden	On-prem Supervisory Review grup yapıları ile Purview grup/policy kapsamlarının birebir örtüşmemesi ve VIP kullanıcıların politika kapsamına dahil edilmemesi.
Çözüm	Üst yönetim için ayrı bir High-Risk Policy oluşturulması. Executive-first dönüşüm modeli ile VIP kullanıcıların ilk taşınan grup olması. Policy kapsamlarının her gün coverage report ile doğrulanması. Mail flow’un VIP grupları için cloud-first olacak şekilde zorunlu hâle getirilmesi.

8.2 Hatalı Mail Flow – Mesajlar Yanlış Yönde Aktı ve Yakalanmadı

Hibrit ortamda bazı kullanıcılar hâlâ on-prem Exchange üzerinden dışarıya e-posta gönderiyordu. Purview politikaları sadece O365 üzerinden akan trafiği denetlediği için bu e-postalar Purview’a ulaşmadı.

Başlık	Açıklama
Sonuç	Dışarıya gönderilen birçok kritik e-posta Purview tarafından hiç yakalanmadı. Compliance ekibi haftalar boyunca bu trafikten habersiz kaldı ve ciddi bir denetim boşluğu oluştu.
Kök Neden	Hibrit ortamda outbound mail flow’un bir kısmının hâlâ on-prem Exchange üzerinden çalışması ve Purview’un yalnızca O365 üzerinden akan trafiği denetlemesi nedeniyle mesajların Purview signal pipeline’ına hiç ulaşmaması.
Çözüm	Tüm outbound trafiğin cloud-first routing modeliyle O365 üzerinden zorunlu geçirilmesi. On-prem → internet direkt çıkışlarının tamamen kapatılması. Hybrid Connector yapılandırmasının yeniden doğrulanması. Transport kurallarının sadeleştirilmesi ve çakışmaların temizlenmesi. Routing sonrası signal visibility test yapılarak mesajların Purview pipeline’a ulaştığının doğrulanması.

8.3 Görünmeyen Kullanıcı Trafiği – Teams ve OneDrive Denetlenmiyor

On-prem SR sadece e-postayı denetliyordu. Purview’a geçildikten sonra IT ekibi politikaları e-posta odağında tasarladığı için Teams mesajları, OneDrive dosya aktiviteleri veya SharePoint paylaşımları politika kapsamına alınmadı.

Başlık	Açıklama
Sonuç	Teams sohbetleri, OneDrive dosya aktiviteleri ve SharePoint paylaşımları politika kapsamında olmadığı için kritik bilgi sızıntıları tamamen görünmez kaldı. Purview yalnızca e-posta trafiği üzerinde çalıştığı için çok kanallı riskler tespit edilemedi.
Kök Neden	Purview politikalarının yalnızca e-posta odaklı tasarlanması, Teams / OneDrive / SharePoint sinyallerinin Purview’a bağlanmamış olması ve çok kanallı denetim yeteneklerinin aktive edilmemesi.
Çözüm	Purview üzerinde multi-channel (çok kanallı) policies aktif edilmelidir. Teams, OneDrive ve SharePoint sinyalleri Purview Signal API üzerinden bağlanmalıdır. AI tabanlı davranış ve içerik sınıflandırıcılar devreye alınmalıdır. OneDrive/SharePoint paylaşım aktiviteleri için real-time alerting etkinleştirilmelidir. “Non-email channels” için ayrı yüksek risk politikaları oluşturulmalıdır.

8.4 Case Yönetimi Kaosu – Reviewer Ekibi Yeni Sisteme Hazır Değildi

On-prem SR’de denetçiler sadece sade bir “Uygun / İhlal” arayüzüne alışmıştı ve Purview tarafında Case’ler,  Alerts, Disposition süreci, Policy matches, Audit logları gibi kavramlar bir araya gelince Reviewer ekibi sistemi yönetmekte zorlandı.

Başlık	Açıklama
Sonuç	Reviewer ekibi Purview’ın gelişmiş denetim arayüzüne ve case yönetim süreçlerine uyum sağlayamadı. Hatalı işaretlemeler, yanlış kapatılan vakalar ve geciken ihlal bildirimleri nedeniyle denetim zinciri yavaşladı ve bazı kritik ihlaller zamanında fark edilemedi.
Kök Neden	On-prem Supervisory Review’in basit “Uygun / İhlal” odaklı arayüzüne alışmış olan denetçilerin, Purview’ın case management, alerts, escalation, disposition process ve audit trail gibi kapsamlı fonksiyonlarını kullanmak için yeterli eğitim almamış olması. Pilot test yapılmadığı için ekip yeni sisteme gerçek senaryolarla hazırlanamadı.
Çözüm	Reviewer ekibi için 3 aşamalı eğitim programı: Arayüz eğitimi: Case, alert, policy match, disposition ekranlarına hâkimiyet. Örnek vakalar: Gerçek olaylardan türetilmiş vaka incelemeleri. Simülasyon: Sahte ihlal olaylarıyla pratik yapma. En az 1 aylık pilot çalışma uygulanması. Kritik vakalar için two-step review modeli kullanılması (çift onay mekanizması). Reviewer performansının Purview raporları ile düzenli analiz edilmesi.

9. Sonuç ve Sonraki Adımlar

Purview’a geçiş, sadece teknoloji güncellemek değildir; kurumun iletişim güvenliği, regülasyon uyumluluğu ve risk yönetimi anlayışını üst seviyeye taşımaktır. Bu yolculuğun her adımında doğru tasarım, kontrollü uygulama ve sürekli denetim yaklaşımı kritik öneme sahiptir.

Bu makale, Supervisory Review ‘ den Purview dönüşüm stratejilerinin nasıl tasarlanması gerektiğini anlattığımız kapsamlı bir rehber niteliğindeydi. Ancak bu yolculuk burada bitmiyor. Serinin bir sonraki makalelerinde şu konulara derinlemesine odaklanacağız: