Doküman Kontrolü: Sürüm, Onay ve Dağıtım Nasıl Yönetilir?

Prosedür doğru yazılmış olabilir; sahada eski sürüm kullanılıyorsa bunun bir anlamı kalmaz. Onay kaydı yoksa ya da aynı dokümanın üç farklı kopyası dolaşıyorsa denetçi bunu kontrol eksikliği olarak yazar. Doküman kontrolü, bir BGYS’de en az göze batan ama en çok bulgu üreten konulardan biridir. Aşağıda ISO/IEC 27001:2022 Madde 7.5 gerekliliklerini numaralandırma, sürüm, onay, dağıtım ve arşiv kurallarına çeviriyoruz.

Doküman kontrolü neden bulgu kaynağıdır?

Madde 7.5.2, dokümante bilgi oluşturulurken ve güncellenirken uygun tanımlamanın (başlık, tarih, yazar veya referans numarası gibi), format ve ortamın belirlenmesini, uygunluk ve yeterlilik açısından gözden geçirilip onaylanmasını ister. Madde 7.5.3 ise dokümante bilginin gerektiği yerde ve zamanda kullanılabilir olmasını, yeterince korunmasını; dağıtım, erişim, saklama, değişiklik kontrolü, muhafaza ve elden çıkarma faaliyetlerinin yönetilmesini bekler. Standart bunların nasıl yapılacağını söylemez. Yöntem kuruluşundur.

Denetimde ve sahada en sık gördüğümüz tablolar şunlar:

• Dosya sunucusunda “Yedekleme_Proseduru_son_v3_guncel.docx” gibi adlarla birden fazla sürüm bulunması.
• Dokümanda onaylayanın adı yazmasına rağmen onayın ne zaman ve nasıl verildiğine dair hiçbir iz olmaması.
• Politikanın yürürlük tarihinin, içinde atıf yapılan prosedürden daha eski olması.
• Çalışanların intranetteki sürüm yerine e-postayla gelmiş eski PDF’yi kullanması.
• Kuruluşun dayandığı dış dokümanların (standart, müşteri gereklilikleri, üretici kılavuzları) hangi sürümünün geçerli olduğunun bilinmemesi.

Hepsinin kökü aynı: dokümanlar tek bir doğruluk kaynağından yönetilmiyor. Aşağıdaki kurallar o kaynağı tanımlamak için.

Numaralandırma ve sürüm şeması

Numaralandırmanın amacı her dokümana tekil ve kalıcı bir kimlik vermektir. Doküman adı değişebilir. Numara değişmez. Sade ve yaygın bir yapı; sistem kısaltması, doküman türü ve sıra numarasından oluşur:

Biçim : <SİSTEM>-<TÜR>-<SIRA>
Türler: POL (politika), PRS (prosedür), TLM (talimat),
        FRM (form/şablon), LST (liste), PLN (plan)

Örnekler:
BGYS-POL-001  Bilgi Güvenliği Politikası
BGYS-PRS-007  Kullanıcı Hesabı Yaşam Döngüsü Prosedürü
BGYS-TLM-007-02  Entra ID Hesap Devre Dışı Bırakma Talimatı
BGYS-FRM-012  Geri Yükleme Test Formu

Talimatları bağlı oldukları prosedürün numarasıyla ilişkilendirin (TLM-007-02 gibi); etki analizi kolaylaşır, prosedür değiştiğinde hangi talimatların gözden geçirileceği numaradan okunur. Departman kodunu numaraya koymayın. Organizasyon değiştiği gün numaralar anlamını yitirir ve ya herkes eski kodla yaşamaya devam eder ya da toplu yeniden numaralandırma kaosu başlar.

Sürüm şeması için iki seviyeli yapı yeterli:

Sürüm	Anlamı	Onay gerekir mi?
0.1, 0.2 …	Taslak, yürürlükte değil	Hayır
1.0	İlk onaylı yayın	Evet
1.1, 1.2 …	Anlamı değiştirmeyen düzeltme (yazım, bağlantı, rol adı)	Süreç sahibi onayı
2.0, 3.0 …	Kapsamı, sorumlulukları veya kuralları değiştiren revizyon	Tam onay akışı

Küçük ve büyük revizyon ayrımını dokümanda yazılı olarak tanımlayın. Tanım yoksa her değişiklik “küçük” işaretlenir ve onay akışı fiilen devreden çıkar. Sahada bunu çok görürüz.

Hazırlama, kontrol ve onay akışı

Onay akışında üç rol var: hazırlayan (içeriği yazan, genellikle süreç uzmanı), kontrol eden (doğruluğu ve diğer dokümanlarla tutarlılığı gözden geçiren, çoğunlukla BGYS sorumlusu) ve onaylayan (dokümanın yetki seviyesine göre süreç sahibi veya üst yönetim). Küçük organizasyonlarda aynı kişinin hem hazırlayıp hem onaylaması kaçınılmaz olabilir; bu durumda en azından kontrol adımını farklı bir kişiye verin.

1. Hazırlayan, taslağı 0.x sürümüyle doküman deposunda açar ve değişiklik özetini yazar.
2. Kontrol eden; çelişen dokümanları, rol adlarını, kayıt referanslarını ve sınıflandırmayı kontrol eder, yorumlarını taslak üzerinde bırakır.
3. Onaylayan dokümanı onaylar; onay tarihi ve kimliği sistemde (iş akışı kaydı, elektronik imza veya onay e-postasının arşivi) iz bırakır.
4. BGYS sorumlusu sürümü yayımlar, yürürlük tarihini girer, ana listeyi günceller ve önceki sürümü arşive alır.
5. Etkilenen rollere değişiklik bildirimi yapılır; gerekiyorsa kısa bir bilgilendirme veya eğitim kaydı oluşturulur.

Elektronik doküman yönetim sistemi bu adımları otomatik iz bırakarak yürütür. Örneğin SharePoint doküman kitaplıklarında ana ve ara sürüm takibi ile içerik onayı birlikte kullanılabilir; ara sürümleri yalnız düzenleme yetkisi olanlara göstererek taslağın yanlışlıkla kullanılmasını engellersiniz. Kanıt tarafındaki kurgu için SharePoint ile kanıt yönetimi yazısına bakabilirsiniz.

Dağıtım, erişim ve geçersiz doküman yönetimi

Dağıtımın temel kuralı tek cümle: geçerli sürüm yalnız bir yerde yayımlanır, diğer her yer o kaynağa bağlantı verir. Dokümanı e-posta eki olarak dağıtmak, kontrolsüz kopya üretmenin en hızlı yoludur. Ek giden her dosya bir kopyadır.

• Okuma ve düzenleme yetkisini ayırın. Madde 7.5.3’teki “erişim”, yalnız görüntüleme ya da görüntüleme ve değiştirme izni anlamına gelebilir. Yayımlanmış dokümanı yalnız BGYS sorumlusu ve doküman sahibi değiştirebilmeli.
• Sınıflandırmayı dağıtıma yansıtın. “Kuruma özel” bir prosedür intranette herkese açık olabilir; “gizli” sınıftaki bir ağ topolojisi talimatı yalnız ilgili ekibe açılır.
• Basılı kopyaları işaretleyin. Sahada kullanılan basılı talimatlar için şablona “Basılı kopya kontrolsüzdür, geçerli sürümü depodan doğrulayın” ibaresi eklenir; kontrollü basılı kopya gerekiyorsa dağıtım listesi tutulur.
• Geçersiz sürümleri ayırın. Yürürlükten kalkan sürüm silinmez; okunabilir ama yayın alanından ayrı bir arşivde, “Geçersiz” işaretiyle tutulur. Geçmiş bir olay, o tarihte geçerli kurala göre değerlendirilir; o kural elinizde olmalı.

Arşivdeki dokümanların ne kadar saklanacağı kayıt saklama kurallarıyla birlikte belirlenir; ayrıntısı kayıt listesi ve saklama süreleri yazısında.

Dış kaynaklı dokümanların kontrolü

Madde 7.5.3, BGYS’nin planlanması ve işletilmesi için gerekli görülen dış kaynaklı dokümante bilginin de tanımlanıp kontrol edilmesini ister. Dış kaynaklı doküman, kuruluşun yazmadığı ama uymak veya kullanmak zorunda olduğu belgedir: standartlar, mevzuat metinleri, müşteri bilgi güvenliği gereklilikleri, sözleşme ekleri, üretici güvenlik kılavuzları.

Bu dokümanların içeriğini değiştiremezsiniz. Ama hangi sürümünün geçerli olduğunu, kimin takip ettiğini ve güncelliğinin hangi sıklıkla kontrol edileceğini tanımlayabilirsiniz. Pratik yöntem, ana listede “dış kaynak” türü için ek alanlar açmaktır: kaynak kuruluş, yayın tarihi veya sürüm, erişim yeri, takipten sorumlu rol ve son kontrol tarihi. Telif kısıtlı standart metinleri genel paylaşım alanına konmaz; lisans koşullarına göre yalnız yetkili kişilere açılır.

Doküman ana listesi örnek alanları

ISO/IEC 27001 “ana liste” adında bir şey istemez. Yine de dokümanları tanımlamanın, sürüm ve onay durumunu izlemenin en pratik aracı budur. Liste elle tutulmak zorunda da değil; elektronik doküman sisteminin meta verilerinden üretilebilir.

Alan	Açıklama	Örnek
Doküman no	Kalıcı, tekil kimlik	BGYS-PRS-007
Başlık	Güncel doküman adı	Kullanıcı Hesabı Yaşam Döngüsü
Tür / kaynak	İç veya dış kaynaklı, doküman türü	İç / Prosedür
Sürüm	Yürürlükteki sürüm	2.1
Yürürlük tarihi	Onaylı sürümün geçerlilik başlangıcı	Gün.Ay.Yıl
Sahip	İçerikten sorumlu rol	BT Altyapı Müdürü
Onaylayan	Onay yetkisi olan rol	BT Direktörü
Sınıflandırma	Erişim seviyesi	Kuruma özel
Sonraki gözden geçirme	Planlanan tarih	Gün.Ay.Yıl
İlgili kontrol	Annex A veya diğer çerçeve eşlemesi	5.16, 5.18

“İlgili kontrol” alanı, SoA ile doküman seti arasındaki izlenebilirliği kurar. Denetçi bir kontrolün hangi dokümanla karşılandığını sorduğunda cevap doğrudan listeden çıkar; klasör klasör arama yapılmaz.

Periyodik gözden geçirme takvimi

Annex A 5.1, bilgi güvenliği politikalarının planlı aralıklarla ve önemli değişiklik olduğunda gözden geçirilmesini ister. Pratikte bu kural tüm doküman setine uygulanır. Ama bütün dokümanları aynı ayda gözden geçirmeye kalkmak yığılma yaratır ve gözden geçirme imza atmaya dönüşür. Takvimi yıla yayın ve iki tür tetikleyici tanımlayın:

• Takvim tetikleyicisi: politika ve prosedürler için genellikle yıllık; hızlı değişen talimatlar için daha sık. Sıklık kurumun kendi kararıdır ve doküman kontrol prosedüründe yazılır.
• Olay tetikleyicisi: organizasyon değişikliği, yeni sistem veya sistem değişikliği, olay sonrası değerlendirme, denetim bulgusu, risk değerlendirmesi sonucu, dış dokümanın yeni sürümü.

Gözden geçirme değişiklik gerektirmese bile karar kaydedilir; “gözden geçirildi, değişiklik yok” notu ve tarihi revizyon geçmişine veya ana listeye işlenir. Not yoksa denetçi, yıllardır değişmemiş bir dokümanın gözden geçirilip geçirilmediğini doğrulayamaz.

Kurulum için kontrol listesi

• Doküman kontrol prosedürü yazıldı; numaralandırma, sürüm ve onay kuralları tanımlandı.
• Tek bir doküman deposu belirlendi; yayın ve taslak alanları ayrıldı.
• Okuma ve düzenleme yetkileri rol bazlı atandı.
• Ana liste oluşturuldu; dış kaynaklı dokümanlar da listede.
• Geçersiz sürümler için arşiv alanı ve saklama süresi belirlendi.
• Gözden geçirme takvimi yıla yayıldı ve sorumlular atandı.

En çok emek isteyen adım genellikle mevcut dosyaların bu yapıya taşınmasıdır. Taşımadan önce hangi dokümanların gerçekten gerektiğine karar verin; bunun için ISO 27001 doküman seti yazısını, yazım kuralları için prosedür ve talimat yazımı rehberini kullanabilirsiniz. Doküman setinin bütün olarak hazırlanması ve yapılandırılması ISO 27001 dokümantasyon hazırlama çalışmamızın parçasıdır. Madde 7.5’in resmi metni için ISO/IEC 27001 sayfası esas alınmalıdır.

Sık sorulan sorular

ISO 27001 doküman ana listesi tutmayı zorunlu kılar mı?

Hayır, standart “ana liste” adıyla bir doküman istemez. Ancak Madde 7.5 dokümanların tanımlanmasını, sürüm ve değişikliklerinin kontrolünü ister; ana liste veya doküman yönetim sisteminden üretilen eşdeğer bir rapor bunu göstermenin en pratik yoludur.

Geçersiz hale gelen eski sürümler silinmeli mi?

Hayır. Eski sürüm yayın alanından kaldırılır ve “Geçersiz” işaretiyle ayrı bir arşivde tutulur. Geçmiş bir olay veya karar o tarihte geçerli kurala göre değerlendirildiği için bu sürümlere belirli bir süre erişilebilmelidir.

Küçük bir yazım düzeltmesi için de onay akışı işletilmeli mi?

Anlamı değiştirmeyen düzeltmeler için kısaltılmış bir akış tanımlanabilir; örneğin yalnız süreç sahibinin onayı ve ara sürüm numarası. Bu ayrımın kriteri doküman kontrol prosedüründe yazılı olmalıdır.

Değişiklik gerekmediğinde gözden geçirme nasıl kanıtlanır?

Gözden geçirme tarihi, gözden geçiren rol ve “değişiklik gerekmedi” kararı revizyon geçmişine veya ana listeye kaydedilir. Bu kayıt olmadan uzun süre değişmemiş bir dokümanın gözden geçirildiği doğrulanamaz.