Değişiklik Yönetimi Denetim Kanıtı: Talep, Onay ve Test Kaydı

Denetçi tek bir değişiklik biletini açıp hem sürecin tasarımını hem de işletimini görebilir; bu yüzden değişiklik yönetimi hemen her ITGC ve ISO 27001 denetiminde örneklenir. Bilet açılmış olması yetmez. Değişikliğin talep edildiği, riskinin değerlendirildiği, uygulamadan önce onaylandığı, test edildiği ve geri dönüş planının olduğu kayıtlarla gösterilmelidir. Aşağıda değişiklik popülasyonunun hazırlanmasından sistem kayıtlarıyla bilet mutabakatına kadar BT ekibinin hazırlık sırasını anlatıyoruz.

Denetçi değişiklik sürecini nasıl test eder?

ISO/IEC 27001:2022 Ek A’da A.8.32 (Değişiklik yönetimi), bilgi işleme tesislerinde ve sistemlerde yapılan değişikliklerin değişiklik yönetimi prosedürlerine tabi olmasını ister; A.8.9 yapılandırma yönetimini, A.8.31 geliştirme, test ve üretim ortamlarının ayrılmasını ele alır. ITGC denetimlerinde program değişiklikleri ayrı bir kontrol alanıdır; genel çerçeve için ITGC kontrolleri rehberine bakın.

Denetçinin yaklaşımı genellikle üç adımdır:

1. Popülasyon talebi: Denetim dönemindeki tüm değişikliklerin listesi istenir.
2. Öznitelik testi: Listeden seçilen her örnek için talep, onay, test, uygulama ve kapanış kanıtı tek tek kontrol edilir.
3. Ters yön testi: Sistem tarafında gerçekleşmiş bir değişiklik (yama, yapılandırma, kod dağıtımı) seçilir ve bilet sisteminde karşılığı aranır.

Üçüncü adım popülasyonun eksiksizliğini sınar. Hazırlıksız ekipler en çok burada takılır: bilet listesi temiz görünür, ama switch’in yapılandırma arşivinde biletsiz bir değişiklik çıkar. Tasarım ile işletim etkinliği arasındaki farkı kontrol etkinliği testi yazısı ayrıntılı açıklar.

Değişiklik popülasyonunun eksiksizliği

Popülasyon, denetim döneminde kapsamdaki sistemlerde yapılan değişikliklerin tamamıdır: başarıyla tamamlananlar, başarısız olup geri alınanlar ve iptal edilenler dahil. Yalnız “kapatılmış” biletleri vermek denetçiye eksik bir resim sunar. Sonradan listede olmayan tek bir değişiklik çıkarsa tüm popülasyonun güvenilirliği sorgulanır.

Dışa aktarımda asgari şu alanlar bulunmalı: bilet numarası, değişiklik türü, etkilenen sistem, talep eden, onaylayan ve onay zamanı, planlanan ve gerçekleşen uygulama zamanı, uygulayan, durum ve kapanış zamanı. Kullandığınız filtreyi (tarih aralığı, kategori, sistem) ekran görüntüsü ya da sorgu metniyle birlikte saklayın; denetçi aynı filtreyle aynı sayıya ulaşabilmeli. Örneklem büyüklüğünün popülasyona göre nasıl belirlendiğini iç denetimde örneklem seçimi rehberinde bulabilirsiniz.

Değişiklik türlerine göre beklenen kanıtlar

ITIL 4’ün değişiklik etkinleştirme (change enablement) pratiğinde de kullanılan standart, normal ve acil ayrımı, her tür için farklı kanıt beklenmesini sağlar. Prosedürde bu türler tanımlı değilse BT uyum denetimi sırasında denetçi her değişikliği normal değişiklik kanıt seviyesinde arar. Aylık yüzlerce yamayı tek tek normal değişiklik gibi belgelemek zorunda kalırsınız.

Tür	Tanım	Onay	Beklenen kanıt
Standart	Düşük riskli, tekrarlayan, önceden tanımlı	Şablon bir kez onaylanır	Onaylı şablon, uygulama kaydı
Normal	Risk değerlendirmesi gerektiren planlı değişiklik	Uygulama öncesi yetkili veya kurul onayı	Risk, onay, test, uygulama ve geri dönüş planı, kapanış
Acil	Hizmet kesintisi veya kritik açık nedeniyle bekleyemeyen	Kısa yoldan yetkili onayı	Gerekçe, önceden onay izi, sonradan gözden geçirme

Normal bir değişiklikte denetçinin izlemek istediği zincir:

• Talep: Neyin, neden değiştiği; talep eden kişi ve tarih.
• Risk ve etki: Etkilenen sistemler, kesinti ihtiyacı, güvenlik etkisi.
• Onay: Onaylayanın adı ve zaman damgası; damga uygulama zamanından önce olmalı.
• Test: Test ortamı sonucu veya kabul testi kaydı; kim test etti, sonuç ne oldu.
• Uygulama: Gerçekleşen tarih ve saat, uygulayan kişi, kullanılan sürüm veya paket.
• Geri dönüş: Planlanan geri alma adımları; başarısızlıkta uygulandıysa kaydı.
• Kapanış: Uygulama sonrası doğrulama ve gerekiyorsa gözden geçirme notu.

Onay ve görevler ayrılığı kanıtı

Görevler ayrılığının özü basit: değişikliği geliştiren veya uygulayan kişi kendi değişikliğini onaylamaz. Denetimden önce dışa aktarımı filtreleyip onaylayan ile uygulayan alanının aynı kişi olduğu kayıtları kendiniz bulun. Yazılım değişikliklerinde Git tabanlı platformların korumalı dal (protected branch) ve zorunlu kod incelemesi ayarları onayı sistem düzeyinde zorunlu kılar; bu yüzden güçlü kanıttır. Ayarın ekran görüntüsünü veya yapılandırma çıktısını, birleştirme isteğinin (pull/merge request) onay kaydıyla birlikte sunun.

Denetçi ayrıca üretim ortamına kimin değişiklik yapma yetkisi olduğunu sorar. Geliştiricilerin üretime doğrudan yazma yetkisi varsa süreç atlanabilir demektir. Prosedür ne yazarsa yazsın. Bu durumda telafi edici bir izleme kontrolü gerekir; örneğin üretim değişikliklerinin dönemsel, bağımsız incelemesi.

Sistem kayıtları ile bilet mutabakatı

Mutabakat, sistemde gerçekten neyin değiştiğini gösteren kayıtlarla bilet listesinin karşılaştırılmasıdır. Ters yön testine kendiniz hazırlanın: dönem sonunda kritik sistemlerden değişiklik izini çıkarın. Aşağıdaki komutlar farklı platformlarda bu izi almak için kullanılabilir:

# Windows: başarıyla kurulan güncellemeler (WindowsUpdateClient, olay 19)
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WindowsUpdateClient'; Id=19; StartTime=(Get-Date '2026-07-01')} |
  Select-Object TimeCreated, Message | Export-Csv .\WU_SRV01_2026H2.csv -NoTypeInformation

# Debian/Ubuntu: paket kurulum ve yükseltmeleri (döndürülmüş loglar dahil)
zgrep -hE ' (install|upgrade) ' /var/log/dpkg.log*

# RHEL ailesi: dnf işlem geçmişi (ayrıntı için: dnf history info <işlem-no>)
dnf history list

# Git: dönem içindeki birleştirmeler
git log main --merges --since="2026-07-01" --until="2026-12-31" --date=iso --pretty=format:"%h;%an;%ad;%s"

# Cisco IOS: yapılandırma değişikliği arşivi ("archive / log config / logging enable" önceden açık olmalı)
show archive log config all

Cisco tarafında sahada sık gördüğümüz hata, archive altındaki yapılandırma loglamasının hiç açılmamış olmasıdır; o zaman geriye dönük iz yoktur ve mutabakat yapılamaz. Çıktıları tarih ve sistem adına göre bilet listesiyle eşleştirin, eşleşmeyen her kaydı sınıflandırın:

Sistem kaydı	Bilet karşılığı	Sonuç
SRV01 aylık güvenlik güncellemeleri	Standart değişiklik şablonu	Uygun; şablona bağlandı
Core switch VLAN eklemesi	Normal değişiklik bileti	Uygun; onay uygulamadan önce
ERP sunucusunda servis yapılandırması	Bilet yok	Sapma; açıklama ve DÖF gerekli

Bu tablo örnek bir çalışma şablonudur. Biletsiz değişikliği denetimden önce siz bulup kök nedenini ve düzeltici faaliyetini kaydettiyseniz, aynı durumu denetçinin bulmasından çok daha iyi bir konumdasınız. Sunucu yamalarının nasıl planlandığı için sunucu yama yönetimi rehberi tamamlayıcıdır. Yapılandırma temellerinin izlenmesinde NIST’in SP 800-128 yayını güvenlik odaklı yapılandırma yönetimi için iyi bir başvuru kaynağıdır.

Acil değişikliklerin sonradan onayı

Acil değişiklik sürecin atlanması değil, hızlandırılmasıdır. Prosedürde dört unsur tanımlı olmalı: hangi durumların acil sayılacağı, acil onayı kimin verebileceği, onayın hangi kanalla kaydedileceği (bilet, kayıtlı mesajlaşma, telefon sonrası e-posta teyidi) ve tam belgeleme ile gözden geçirmenin kaç iş günü içinde tamamlanacağı.

Denetçi acil değişiklik sayısının dönemler arasındaki seyrine de bakar. Acil kategorisi planlama eksikliğini örtmek veya kurul onayını beklememek için kullanılıyor izlenimi verirse, bu sürecin tasarımına yönelik bir bulguya dönüşebilir. Her hafta acil değişiklik varsa sorun acil değildir. Acil değişikliklerin dönemsel listesini ve gözden geçirme tarihlerini değişiklik kurulu tutanağına eklemek bu sorunun en sade yanıtıdır.

Sık görülen bulgular

• Popülasyonda iptal edilen ve başarısız değişiklikler yok.
• Onay zaman damgası uygulama zamanından sonra.
• Onaylayan ile uygulayan aynı kişi, telafi edici kontrol tanımlı değil.
• Test kaydı “test edildi” ifadesinden ibaret; kim, nerede, hangi sonuçla belli değil.
• Geri dönüş planı her bilette aynı kalıp metin.
• Ağ cihazlarında değişiklik loglaması kapalı; mutabakat yapılamıyor.
• Acil değişikliklerin sonradan gözden geçirmesi yapılmamış.

Üretim ortamındaki MES, PLC ve reçete değişiklikleri farklı riskler taşır ve ayrı ele alınmalıdır; bu konu üretim sistemlerinde değişiklik yönetimi yazısında işleniyor. BT değişiklik sürecinizi denetime hazırlamak için değişiklik, konfigürasyon ve yama yönetimi ile ITGC ve denetim hazırlığı hizmet sayfalarına bakabilirsiniz.

Sık sorulan sorular

Denetçi değişiklik örneklemini nereden seçer?

Kuruluşun sunduğu değişiklik popülasyonundan, yani denetim dönemindeki tüm değişikliklerin listesinden seçer. Popülasyonun eksiksiz olduğunu göstermek kuruluşun sorumluluğundadır; bu yüzden denetçi çoğu zaman ters yönde de test yapar ve sistem kayıtlarından seçtiği bir değişikliğin bilet sistemindeki karşılığını ister.

Otomatik yamalar için her seferinde değişiklik kaydı açmak gerekir mi?

Genellikle gerekmez. Aylık yama döngüsü önceden onaylanmış standart değişiklik olarak tanımlanabilir. Bu durumda kanıt; standart değişiklik şablonunun onayı, yama dağıtım politikası (pilot ve üretim halkaları) ve dağıtım aracının uygulama raporudur. Şart olan, bu kapsamın prosedürde yazılı olması ve mutabakatta otomatik yamaların bu sınıfa bağlanabilmesidir.

Acil değişiklikte onay ne zaman alınmalı?

Uygulamadan önce, yetkili kişinin (acil değişiklik kurulu veya tanımlı yetkili) kısa yoldan onayıyla. Tam belgeleme ve gözden geçirme ise prosedürde belirlenen süre içinde sonradan tamamlanır. Denetimde hem önceden alınan onayın izi hem de sonradan yapılan gözden geçirmenin tarihi aranır.

Küçük bir BT ekibinde görevler ayrılığı nasıl sağlanır?

Temel kural, geliştiren veya uygulayan kişinin kendi değişikliğini onaylamamasıdır. Ekip bunu sağlayamayacak kadar küçükse onayı BT dışındaki bir yönetici verebilir ya da dönemsel olarak bağımsız bir kişi uygulanan değişiklikleri sistem kayıtlarından gözden geçirir. Bu telafi edici kontrol prosedürde tanımlı ve kayıtlı olmalıdır.