Microsoft Purview Records Management, kurumun iş, hukuk ve düzenleyici gereksinimler açısından önem taşıyan kayıtlarını yönetmesini sağlar. İçeriğin kayıt olarak tanımlanması, saklama kurallarının uygulanması ve saklama süresi sonunda değerlendirilmesi bu yaklaşımın temel parçalarıdır.
Bir belgeyi saklamak ile kurumsal kayıt olarak yönetmek aynı kapsamı ifade etmez. Günlük çalışma dosyaları değiştirilebilirken imzalanmış bir sözleşme, onaylanmış karar veya tamamlanmış işlem belgesi için daha kontrollü bir yaşam döngüsü gerekebilir.
Önceki bölümde Data Lifecycle Management kapsamında saklama ve silme yaklaşımını ele aldık. Bu bölümde ise belirli içeriklerin neden kayıt olarak değerlendirildiğini ve bu kararın Purview üzerinde nasıl uygulandığını inceleyeceğiz.
Microsoft Purview Records Management makalesi içinde aşağıda ki bilgileri paylaşacağız.
1. Microsoft Purview Records Management Nedir?
Records Management, kayıt niteliğindeki içeriğin tanımlanması, saklanması ve süre sonunda elden çıkarılmasının yönetilmesine yönelik Purview yeteneklerini kapsar.
Saklama etiketleriyle kayıt tanımlama, file plan, olay temelli saklama ve elden çıkarma incelemesi bu kapsamın önemli bileşenleridir. Microsoft Purview Records Management
Kurum açısından başlangıç sorusu, hangi belgenin hangi gerekçeyle kayıt kabul edildiğidir. Bu karar yalnızca dosya biçimine veya bulunduğu klasöre dayanmaz.
Örneğin aynı sözleşmenin taslağı, imzalanmış sürümü ve görüşme notları farklı yönetim gereksinimlerine sahip olabilir. Kurum bu ayrımları açıklamalı, teknik yapılandırmayı da buna göre oluşturmalıdır.
2. Kurumsal Kayıt Ne Anlama Gelir?
Bu makaledeki kayıt — record ifadesi, kurumun faaliyetini, kararını veya işlemini belgeleyen içerik anlamında kullanılmaktadır. Teknik sistemlerin ürettiği denetim kaydıyla aynı kavram değildir.
İmzalanmış sözleşmeler, onaylanmış prosedürler, yönetim kararları ve tamamlanmış işlem belgeleri kurumun kayıt kategorilerine örnek olabilir. Ancak hangi içeriğin kayıt kabul edileceği kurumun iş süreçlerine ve tabi olduğu gereksinimlere göre belirlenmelidir.
Bu nedenle kayıt yönetimi çalışmasına hukuk, uyum, bilgi yönetimi, BT ve ilgili iş birimlerinin katılması yararlı olacaktır.
Bir dosyaya teknik olarak kayıt etiketi uygulanması, belgenin hukuki niteliğini tek başına belirlemez. Kurumsal kararın ve gerekçenin ayrıca bulunması gerekir.
3. Data Lifecycle Management ile Arasındaki Fark
Data Lifecycle Management, genel saklama ve silme ihtiyaçlarını yönetir. Records Management ise kayıt niteliğindeki içeriklere yönelik daha ayrıntılı kontroller sağlar.
İki alan saklama etiketleri gibi ortak mekanizmalardan yararlanır. Dolayısıyla tamamen bağımsız iki sistem şeklinde düşünülmemelidir.
Kurumun ihtiyacını şu sorularla ayırabiliriz:
- İçeriğin belirli süre saklanması yeterli mi?
- İçerik kayıt olarak tanımlanmalı mı?
- Düzenleme veya etiket kaldırma işlemleri sınırlandırılmalı mı?
- Süre bir iş olayından itibaren mi başlamalı?
- Silmeden önce yetkili kişilerin incelemesi gerekiyor mu?
Bu soruların yanıtları, gerekli kontrol düzeyini belirler.
Veri yaşam döngüsünün Exchange tarafındaki temelini Exchange Server Messaging Records Management makalemizde ele almıştık.
4. Saklama Etiketiyle Kayıt Tanımlama
Purview’da belge ve e-postalar, uygun yapılandırılmış retention label — saklama etiketi kullanılarak kayıt olarak tanımlanabilir.
Etiketin oluşturulması, kullanıma sunulması ve içeriğe uygulanması ayrı aşamalardır. Standart kayıt etiketlerinde desteklenen otomatik uygulama yöntemleri kullanılabilir. Regulatory record etiketleri için aynı otomatik uygulama desteği bulunmaz. Saklama etiketleriyle kayıt tanımlama
Kurumun uygulama planında aşağıdaki konular belirlenmelidir:
- Hangi içerik kayıt olarak tanımlanacak?
- Etiketi kim veya hangi mekanizma uygulayacak?
- Yanlış etiketleme nasıl tespit edilecek?
- Kayıt yönetiminden hangi ekip sorumlu olacak?
- Süre sonunda hangi işlem gerçekleştirilecek?
Etiketi yalnızca oluşturmak, bütün ilgili içeriklerin kayıt olarak yönetilmeye başladığını göstermez.
5. Standart Saklama Etiketi, Record ve Regulatory Record
Bu üç yapı aynı kontrol düzeyini sağlamaz.
Standart saklama etiketi, yaşam döngüsü ayarlarını uygular; içeriği mutlaka kayıt olarak tanımlamaz.
Record, kayıt yönetimine yönelik işlem kısıtlamaları getirir. Desteklenen SharePoint ve OneDrive senaryolarında kilitli veya kilidi açık durumlar bulunabilir.
Regulatory record, daha katı kısıtlamalar sağlar. İçeriğe uygulanan etiket, Global Administrator dahil kullanıcılar tarafından kaldırılamaz. Kayıt türleri ve işlem kısıtlamaları
| Yapı | Temel amaç | Önemli ayrım |
|---|---|---|
| Standart saklama etiketi | İçeriğin saklama ve süre sonu davranışını yönetmek | Tek başına kayıt tanımlaması oluşturmaz |
| Record | İçeriği kayıt olarak yönetmek ve ilgili işlemleri sınırlandırmak | İşlem davranışı kayıt durumu, hizmet ve ayarlara bağlıdır |
| Regulatory record | Daha katı kayıt kısıtlamaları uygulamak | Uygulanmış etiket kaldırılamaz; saklama süresi kısaltılamaz |
Regulatory record seçeneği varsayılan olarak gösterilmez; ayrıca etkinleştirilmesi gerekir. Geri alınamayan etkileri nedeniyle gerçek içeriklere uygulanmadan önce uygunluğu doğrulanmalıdır. Regulatory record yapılandırması
Daha katı seçeneğin her kurum için daha uygun olduğu varsayılmamalıdır. Kontrol seviyesi, gerçek gereksinime göre belirlenmelidir.
6. Kayıt Kilitleme ve Sürüm Yönetimi
SharePoint ve OneDrive’da desteklenen record versioning, kayıt üzerinde kontrollü güncelleme yapılmasını sağlayabilir. Kilitleme ve kilidi açma davranışları, kayıt sürümlerinin korunmasıyla birlikte çalışır. Kayıt sürüm yönetimi
Bu yaklaşım, kayıt olarak yönetilen bir belgenin belirli iş süreçlerinde güncellenmesi gerektiğinde değerlendirilebilir.
Ancak kilidin açılması, içeriğin serbestçe silinebileceği anlamına gelmez. Kayıt üzerindeki işlemler ilgili kısıtlamalara tabidir.
Bu sürüm yönetimi Exchange öğeleri için desteklenmez. E-posta kayıtlarıyla belge kayıtlarının davranışı aynı kabul edilmemelidir. Hizmetlere göre kayıt kısıtlamaları
7. File Plan — Kayıt ve Saklama Planı
File plan, saklama etiketlerinin merkezi biçimde yönetilmesini ve kurumsal saklama planıyla ilişkilendirilmesini destekler.
İşlev veya departman, kategori, dayanak ve referans gibi ek bilgiler kullanılabilir. Mevcut etiket bilgileri dışarı aktarılabilir; uygun şablon üzerinden toplu etiket oluşturma yapılabilir.
File plan yalnızca kayıt tanımlayan etiketlerle sınırlı değildir; diğer saklama etiketleri için de kullanılabilir. File plan ile etiket yönetimi
Kurumsal açıdan bu alanın değeri, teknik ayarla iş gerekçesini birlikte görünür hale getirmesidir.
Örneğin “Sözleşme Kaydı” etiketinin süresi kadar hangi kategoriye ait olduğu, hangi karara dayandığı ve kim tarafından gözden geçirildiği de açıklanmalıdır. Girilen dayanak bilgisi, teknik ayarı kendiliğinden hukuken doğrulamaz.
8. Olay Temelli Saklama
Her saklama süresi belgenin oluşturulduğu tarihten başlamaz. Bazı gereksinimlerde sözleşmenin sona ermesi, çalışanın ayrılması veya ürünün kullanım ömrünün tamamlanması başlangıç noktası olabilir.
Event-based retention — olay temelli saklama, ilgili olay tarihini saklama süresinin başlangıcı olarak kullanmayı sağlar. Olay türü, etiket ve içerik eşleştirmesi birlikte yapılandırılır. SharePoint ve OneDrive belgelerinde asset ID, Exchange öğelerinde uygun anahtar kelimeler kullanılabilir. Olay temelli saklama
Örneğin bir sözleşme kategorisinin, sözleşme bitiminden itibaren kurumun belirlediği süreyle saklanması istenebilir. Bu, bütün sözleşmeler için geçerli yasal süre önerisi değil, yapılandırma örneğidir.
Olayın gerçekleşmesi, Purview’ın bunu başka bir sistemden kendiliğinden öğrendiği anlamına gelmez. Olayın oluşturulması veya entegrasyonla iletilmesi planlanmalıdır.
Kayıt olarak tanımlanmış olay temelli içerikte tetikleyicinin oluşturulmaması, sürenin başlamamasına ve içeriğin beklenenden uzun tutulmasına neden olabilir.
9. Disposition Review — Elden Çıkarma İncelemesi
Disposition review, saklama süresi sonunda içeriğin silinmeden önce yetkili kişiler tarafından değerlendirilmesini destekler.
Yapılandırmaya göre inceleme birden fazla aşamadan oluşabilir. İnceleyiciler, desteklenen seçenekler kapsamında kalıcı silmeyi onaylayabilir, saklama süresini uzatabilir veya başka bir etiket uygulayabilir. İçeriğin elden çıkarılması
Bu süreç, süre dolduğunda iş ihtiyacının veya inceleme gereksiniminin devam edip etmediğini değerlendirmek için kullanılabilir.
Kurumun yalnızca reviewer ataması yapması yeterli değildir. İnceleme sıklığı, karar gerekçeleri, yedek sorumlular ve bekleyen işlerin takibi belirlenmelidir.
İnceleme için bekleyen kayıtlar düzenli takip edilmezse, planlanan yaşam döngüsü tamamlanamayabilir.
10. Silme Onayı ve Diğer Koruma Gereksinimleri
Elden çıkarma incelemesinde silme kararı verilmesi, başka bir saklama veya hukuki koruma gereksiniminin otomatik olarak kaldırıldığı anlamına gelmez.
Aynı içerikte birden fazla saklama ayarı veya hold bulunabilir. Nihai davranış, geçerli korumalar ve hizmetin işleme süreçleriyle birlikte değerlendirilmelidir. Saklama ayarlarının etkileşimi
Kurumun inceleyicilere yalnızca süre bilgisini değil, devam eden iş ve araştırma ihtiyaçlarını da aktaracak bir süreç kurması gerekir.
Bu ilişkinin hukuki inceleme tarafını Supervisory Review Dava Yönetimi makalemizde ele almıştık.
11. Silme Kanıtı ve Denetim İzleri
Records Management, uygun kapsamda elden çıkarılan kayıtların bilgilerini ve inceleme kararlarını takip etmeyi destekler. İlgili bilgiler dışarı aktarılarak kurumsal denetim çalışmalarında kullanılabilir. Elden çıkarma ve silme bilgileri
Bu kanıtın kapsamı doğru anlaşılmalıdır. Yönetilen öğenin silinmesine ilişkin bilgi, kurum dışına çıkarılmış bütün kopyaların veya başka sistemlerdeki verilerin silindiğini göstermez.
Kurumun hangi kaydın, hangi kurala göre ve hangi karar süreciyle elden çıkarıldığını açıklayabilmesi önemlidir. Denetim kanıtlarının ne kadar süre korunacağı da ayrıca planlanmalıdır.
Denetim yaklaşımının temelini Exchange Server Audit Logging ve Supervisory Review Veri ve Denetim Boyutu makalelerimizde incelemiştik.
12. Kayıt Yönetimi ile Bilgi Koruma Arasındaki İlişki
Bir belge hem hassas bilgi içerebilir hem de kurumsal kayıt niteliğinde olabilir. Ancak bu iki ihtiyaç farklı soruları yanıtlar.
Information Protection, içeriğin hassasiyeti ve erişim korumasıyla ilgilenir. Records Management, kayıt statüsü ve yaşam döngüsü kontrollerini yönetir.
Kayıt olarak tanımlanmış bir belge, yalnızca bu nedenle şifrelenmiş olmaz. Benzer şekilde “Gizli” etiketi taşıyan bir belge de otomatik olarak kayıt statüsü kazanmaz.
Kurumun erişim, paylaşım, saklama ve kayıt kararlarını birlikte tasarlaması gerekir.
13. Kurumlar İçin Uygulama Senaryoları
13.1 İmzalanmış Sözleşmeler
Taslaklarla imzalanmış sözleşmelerin farklı yönetilmesi gerekebilir.
Öneri: Kayıt tanımlama noktası, sözleşme kimliği ve saklama başlangıcı açıkça belirlenmelidir. Süre sözleşmenin sona ermesine dayanıyorsa olayın kim tarafından oluşturulacağı planlanmalıdır.
13.2 Onaylanmış Prosedürler
Yeni sürüm yayımlandığında önceki onaylı sürümlerin korunması gerekebilir.
Öneri: Belge onay süreciyle kayıt sürüm yönetimi birlikte değerlendirilmelidir. Yeni sürümün yayımlanması ve eski sürümün saklanması ayrı kararlar olarak ele alınmalıdır.
13.3 Personel Kayıtları
Çalışanla ilgili belgelerin farklı kategorileri ve saklama gerekçeleri olabilir.
Öneri: İşten ayrılma olayı kullanılacaksa ilgili içeriklerin doğru kişiyle eşleştirilmesi ve olay bilgisinin güvenilir kaynaktan gelmesi sağlanmalıdır.
13.4 Yüksek Kısıtlama Gerektiren Kayıtlar
Bazı kayıtlar için daha katı değiştirme ve etiket kaldırma kısıtlamaları gerekebilir.
Öneri: Regulatory record seçimi, ilgili gereksinim doğrulandıktan ve testler tamamlandıktan sonra değerlendirilmelidir. Bütün belgelere varsayılan olarak uygulanmamalıdır.
14. Lisanslama ve Yetkilendirme
Records Management lisans gereksinimleri kullanılan özelliklere bağlıdır. Kayıt tanımlama, olay temelli saklama ve elden çıkarma incelemesi için özellik bazında kontrol yapılmalıdır.
Politika yapılandıran kişinin bütün kayıt içeriklerine erişmesi gerekmez. İnceleyicilerin içerik erişimi ve elden çıkarma görevleri ayrıca planlanmalıdır. Records Management başlangıç, lisans ve izinler
Kurumun iş sahibi, teknik yönetici ve inceleyici sorumluluklarını ayırması yararlı olacaktır. Görevlerin ayrılmasına ilişkin yaklaşımı Supervisory Review Süreç ve Roller makalemizde açıklamıştık.
15. Başlangıç ve İşletim Planı
Records Management çalışması için aşağıdaki sıra izlenebilir:
- Kayıt kategorilerini belirlemek: Hangi içerikler kayıt kabul edilecek?
- Gerekçeleri kaydetmek: Saklama ve kısıtlama kararları hangi ihtiyaca dayanıyor?
- File plan hazırlamak: Kategoriler, dayanaklar ve sorumlular nasıl takip edilecek?
- Kayıt türünü seçmek: Standart saklama, record veya regulatory record seçeneklerinden hangisi uygun?
- Süre başlangıcını tanımlamak: Oluşturulma, etiketlenme veya iş olayı mı kullanılacak?
- Uygulama yöntemini belirlemek: Etiket içeriğe nasıl atanacak?
- Süre sonu sürecini hazırlamak: Otomatik işlem mi, inceleme mi gerekecek?
- Pilot test yapmak: Düzenleme, silme, etiket değiştirme ve olay davranışları beklenenle uyumlu mu?
- İşletimi izlemek: Bekleyen incelemeler, tetiklenmeyen olaylar ve değişen sorumluluklar nasıl takip edilecek?
Özellikle katı kayıt seçeneklerinde geri alınamayan etkiler değerlendirilmelidir. Yapılandırma, gerçek içeriklere uygulanmadan önce kontrollü testlerle doğrulanmalıdır.
16. Kayıt Yönetiminden Denetim Süreçlerine
Exchange Server Compliance Management etiketi altındaki çalışmalarımızda olduğu gibi kayıt yönetimi de teknik ayarlarla kurumsal sorumlulukların birlikte yürütülmesine dayanır.
Records Management, hangi içeriğin kayıt kabul edildiğini ve bu kaydın yaşam döngüsünün nasıl yönetileceğini uygulanabilir kontrollere dönüştürür. Etiketin yanında iş gerekçesi, olay bilgisi, inceleme sorumluluğu ve denetim kanıtı da önem taşır.
Bir sonraki bölümde kullanıcı ve yönetici işlemlerinin nasıl araştırılabildiğini Microsoft Purview Audit üzerinden inceleyeceğiz.
