Prosedür ve Talimat Yazımı: Fark, Yapı ve Örnek Şablon

Prosedürün iyi olup olmadığını tek bir test gösterir: işi ilk kez yapacak çalışan, metni okuyup işi doğru bitirebiliyor mu? Denetimde en sık çıkan sorun prosedürün hiç olmaması değil. Politikayı kelime kelime tekrar eden, kimin ne yapacağını söylemeyen ve sahadaki uygulamayla hiç örtüşmeyen metinler çıkıyor. Aşağıda BT ve bilgi güvenliği ekipleri için politika–prosedür–talimat ayrımını, prosedür şablonunun bölümlerini ve adım yazım kurallarını örnekleriyle veriyoruz.

Politika, prosedür ve talimat hiyerarşisi

Üç doküman aynı soruya farklı derinlikte cevap verir. Politika “ne istiyoruz ve neden” der. Prosedür “süreç hangi adımlarla, kimler tarafından yürür” sorusunu cevaplar. Talimat ise “bu işi bu sistemde tuş tuş nasıl yaparım” sorusuna iner. Hiyerarşi karışınca iki tipik arıza çıkar: ekran adımları politikaya yazıldığı için politika her sistem değişikliğinde revize edilir ya da prosedür o kadar genel kalır ki içinde ölçülebilir tek bir şey bulunmaz.

Özellik	Politika	Prosedür	Talimat
Soru	Ne ve neden?	Kim, ne, ne zaman?	Tam olarak nasıl?
Okur	Tüm çalışanlar, yönetim	Süreç rolleri	İşi yapan uzman
Onay	Üst yönetim	Süreç sahibi	Ekip lideri / süreç sahibi
Değişim sıklığı	Düşük	Orta	Yüksek (sistem değiştikçe)
Örnek	Erişim kontrol politikası	Kullanıcı hesabı yaşam döngüsü prosedürü	Entra ID’de misafir hesabı kapatma talimatı

ISO/IEC 27001:2022 her konu için ayrı prosedür istemez. Madde 7.5, kuruluşun BGYS’nin etkinliği için gerekli gördüğü dokümante bilgiyi kendisinin belirlemesini ister; Annex A 5.37 ise bilgi işleme tesislerine ilişkin işletim prosedürlerinin dokümante edilmesini ve ihtiyaç duyan personele erişilebilir olmasını bekler. Hangi sürecin prosedüre bağlanacağına üç soruyla karar verin: süreç ne kadar riskli, kaç kişi yürütüyor, hata olursa bedeli ne? Üst politikanın kurgusu için bilgi güvenliği politikası yazım rehberine, hangi dokümanların gerçekten gerektiğine dair genel tablo için ISO 27001 dokümanları yazısına bakabilirsiniz.

Prosedür şablonunun bölümleri

Bütün prosedürlerde aynı iskeleti kullanın; özellikle bir bilgi güvenliği politika ve prosedür paketi hazırlanırken bu, hem okuru hem denetçiyi hızlandırır. Okur neyin nerede olduğunu bilir. Çoğu BT ve BGYS prosedürü için şu bölümler yeterlidir:

1. Doküman künyesi: doküman numarası, sürüm, yürürlük tarihi, hazırlayan, onaylayan, sınıflandırma. Sürüm ve onay kurallarının nasıl işletileceği doküman kontrolü ve revizyon yönetimi yazısında ayrıca anlatılıyor.
2. Amaç: bir iki cümle. Prosedür hangi riski azaltıyor, hangi politika maddesini uyguluyor.
3. Kapsam: hangi sistemler, lokasyonlar, kullanıcı grupları dahil; neler bilerek hariç. “Tüm BT sistemleri” gibi sınırsız ifade yazmayın, kapsamı listeleyin.
4. Tanımlar ve kısaltmalar: yalnız bu dokümanda farklı anlamda kullanılan terimler.
5. Roller ve sorumluluklar: kişi adı değil, rol adı. Her rolün bu süreçteki yetkisi.
6. Girdiler ve tetikleyiciler: süreci ne başlatır (talep kaydı, takvim, alarm, İK bildirimi).
7. Adımlar: numaralı akış; gerekiyorsa karar noktaları ve süre hedefleri.
8. Kayıtlar: süreç sonunda hangi kanıt, nerede, ne kadar süre tutuluyor.
9. İlgili dokümanlar: üst politika, talimatlar, formlar.
10. Revizyon geçmişi: sürüm, tarih, değişikliğin özeti.

Sahada en zayıf bölüm neredeyse her zaman “Kayıtlar”dır. Oysa denetçi prosedürün işletildiğini yalnızca kayıttan doğrulayabilir. Kayıt yoksa iş yapılmamış sayılır. Her adımın sonunda “bu adım bir iz bırakıyor mu?” diye sorun; bölüm kendiliğinden dolar.

Adım yazımı: kim, ne, ne zaman, hangi kayıt

İşleyen bir prosedür adımında dört öğe bulunur: rol (kim), eylem (ölçülebilir fiil), zamanlama (tetikleyici veya süre) ve çıktı (kayıt). Biri eksikse adım ya uygulanamaz ya da uygulandığı kanıtlanamaz.

• Aktif cümle kurun. “Hesap kapatılır” yerine “Sistem yöneticisi hesabı kapatır”. Edilgen cümle sorumluyu metinden siler; olay günü kimse işin kendisine ait olduğunu düşünmez.
• Bir adım, bir eylem. “Talebi inceler, onaylar ve uygular” üç farklı rolün işi olabilir; ayırın.
• Ölçülebilir fiil seçin. “Takip eder”, “dikkat eder”, “gerekli önlemleri alır” denetlenemez. “Kaydeder”, “onaylar”, “devre dışı bırakır”, “raporlar” denetlenir.
• Süreyi yazın. “En kısa sürede” yerine “ayrılış tarihinden sonraki ilk iş günü sonuna kadar”. Süreyi kurumun gerçekten tutturabileceği değerde belirleyin; kâğıt üstündeki iddialı süre, ilk denetimde bulguya döner.
• İstisnayı adımın yanında verin. Acil durumda veya sistem erişilemezken sapmanın kimin onayıyla yapılacağını aynı yerde yazın.
• Karar noktasını açık bırakmayın. Metinde “gerekirse” gördüğünüz her yere gerekliliğin kriterini ekleyin.

Talimatta teknik detay seviyesi

Talimat, prosedürdeki tek bir adımın sistem üzerinde nasıl yapılacağını anlatır ve prosedürden ayrı numaralanır. Bu ayrım boşuna değil: yönetim konsolunun arayüzü değiştiğinde yalnız talimat revize edilir, prosedürün onay zinciri yeniden dönmez. Detay seviyesi için ölçüt basit: o sistemde yetkisi olan ama işi ilk kez yapan bir ekip üyesi, talimatı tek başına bitirebilmeli.

Komut içeren talimatta komutun kendisi, beklenen çıktı ve doğrulama adımı birlikte yazılır. Doğrulamasız komut yarım iştir. Active Directory’de ayrılan kullanıcının hesabını devre dışı bırakma talimatından bir bölüm şöyle görünür:

# Adım 3 – Hesabı devre dışı bırak (ActiveDirectory PowerShell modülü)
Disable-ADAccount -Identity "ayse.yilmaz"

# Adım 4 – Doğrula: Enabled değeri False olmalı
Get-ADUser -Identity "ayse.yilmaz" -Properties Enabled, Description |
    Select-Object SamAccountName, Enabled, Description

# Adım 5 – Açıklama alanına talep numarasını yaz
Set-ADUser -Identity "ayse.yilmaz" -Description "Ayrilis - TALEP-2026-0412"

Ekran görüntüsü kullanıyorsanız altına konsol veya yazılım sürümünü not edin. Eski ekran görüntüsü, eksik talimattan daha çok hata üretir; menü yeri değişmiş bir görüntüye bakan uzman yanlış ayarı değiştirir. Parola, anahtar, sunucu IP planı gibi hassas bilgileri talimata yazmayın; bunların tutulduğu kasaya veya sisteme referans verin.

Zayıf ve düzeltilmiş adım örnekleri

Aşağıdaki satırlar kullanıcı hesabı yaşam döngüsü prosedürlerinde sahada sık gördüğümüz adımlar ve düzeltilmiş halleri.

Zayıf ifade	Sorun	Düzeltilmiş ifade
Ayrılan personelin hesapları kapatılır.	Rol, süre ve kayıt yok	BT destek uzmanı, İK’nın ayrılış bildirimini aldığı gün mesai sonuna kadar kullanıcının dizin ve e-posta hesaplarını devre dışı bırakır ve talep kaydını kapatır.
Yetkiler periyodik olarak kontrol edilir.	Sıklık, kapsam ve kontrol eden belirsiz	Her uygulama sahibi, üç ayda bir BT’nin ürettiği yetki listesini gözden geçirir; değişiklik taleplerini aynı hafta içinde açar ve imzalı listeyi BGYS klasörüne yükler.
Gerekli durumlarda yönetici yetkisi verilebilir.	Kriter ve onaylayan yok	Yönetici yetkisi yalnız BT müdürünün onayladığı talep ile ve en fazla talepte belirtilen süre boyunca verilir; süre bitiminde yetki kaldırılır.
Yedekler düzenli olarak test edilir.	“Düzenli” ölçülemez, çıktı tanımlı değil	Sistem yöneticisi her ay en az bir kritik sistemden örnek geri yükleme yapar ve sonucu geri yükleme test formuna kaydeder.

Düzeltilmiş ifadeler uzun. Bu kusur değil. Uzunluğu yönetmek için adımları tabloya ya da “Rol | Eylem | Süre | Kayıt” sütunlu bir akış listesine dökün. Okurların çoğu paragraf halindeki prosedürü değil, bu tabloyu kullanır.

Sık yapılan hatalar

• Standart metnini kopyalamak: Annex A kontrol açıklamasını prosedür adımı gibi yazmak sahada hiçbir şeyi değiştirmez; telif açısından da sorunludur.
• Olmayan bir süreci yazmak: Prosedür ideal süreci değil, kurumun gerçekten işleteceği süreci anlatır. Hedef süreç farklıysa geçiş planı ayrı tutulur.
• Üst dokümanla çelişmek: Prosedürdeki süre, onaylayan veya sıklık; politikadaki ya da bağlı başka bir prosedürdeki değerle uyuşmaz. Yazarken atıf yaptığınız politika maddesini açın, değerleri tek tek karşılaştırın.
• Kaydı tanımlamamak: “Kaydedilir” yazıp nerede ve hangi formatta olduğunu söylememek.
• Bir prosedüre birden fazla süreç sıkıştırmak: Yedekleme, geri yükleme testi ve medya imhasını tek dokümana toplamak revizyonu ve sahipliği zorlaştırır. Üç süreç, üç sahip demektir.

Prosedürü sahada doğrulama

Yayımlamadan önce prosedürün uygulanabilir olduğunu kısa bir doğrulama turuyla gösterin. Kontrol sırası şöyle:

• Süreci yürüten iki farklı kişiyle prosedürü adım adım okuyun; her adımda “bunu bugün böyle mi yapıyorsunuz?” diye sorun.
• Geçmiş dönemden gerçek bir örnek seçin (örneğin son ayrılış talebi) ve prosedürdeki her kaydın gerçekten oluşup oluşmadığını izleyin.
• Süre hedeflerini gerçek verilerle karşılaştırın. Sürekli aşılan süre ya kapasite sorunudur ya da gerçekçi olmayan hedeftir.
• Prosedürde adı geçen form, klasör ve sistemlerin var olduğunu ve erişim yetkilerinin doğru olduğunu kontrol edin.
• Yayından sonraki ilk iç denetimde bu prosedürü örneklem kapsamına alın.

Doğrulamada çıkan sapma iki yönden düzeltilir: ya süreç prosedüre uyacak şekilde değişir ya da prosedür gerçek ve kabul edilebilir uygulamayı yansıtacak şekilde güncellenir. Prosedürün ürettiği kayıtların kanıta nasıl dönüşeceği için planlanan kanıt matrisi rehberi iyi bir tamamlayıcıdır. Bu dokümanları kurumda sistematik olarak kurmak isterseniz kurumsal BT politika, prosedür ve talimat çalışmasında şablon ve sahiplik yapısını birlikte oturtuyoruz. Standardın kendisi hakkında resmi bilgi ISO/IEC 27001 sayfasında yer alır.

Sık sorulan sorular

Her ISO 27001 kontrolü için ayrı prosedür yazmak gerekir mi?

Hayır. ISO/IEC 27001:2022 kuruluşun BGYS’nin etkinliği için gerekli gördüğü dokümante bilgiyi belirlemesini ister. Riskli, çok kişili veya hatası pahalı süreçler prosedüre bağlanır; basit kontroller bir politika maddesi veya kayıt şablonuyla karşılanabilir.

Prosedür ile talimat aynı dokümanda olabilir mi?

Küçük ve az değişen süreçlerde olabilir. Sistem arayüzü sık değişiyorsa talimatı ayrı numaralı doküman olarak tutun; prosedür akışı sabit kalır, yalnız talimat güncellenir.

Prosedürde kişi adı yerine neden rol adı kullanılmalı?

Kişi adı, çalışan değiştiği gün dokümanı geçersiz kılar ve her ayrılışta revizyon gerektirir. Rol adı görev tanımıyla eşleştiğinde sorumluluk kişiden bağımsız sürer.

Bir prosedürün işe yaradığını nasıl anlarız?

Geçmiş dönemden gerçek bir örnek seçin; prosedürde tanımlanan her kaydın oluştuğunu ve süre hedeflerinin tutulduğunu izleyin. Kayıt oluşmuyorsa veya süreler sürekli aşılıyorsa prosedür ya da süreç düzeltilmelidir.