Site Yönetiminde İşlem Kayıtları Neden Önemlidir?

Audit log nedir? En kısa tanımıyla audit log, bir sistemdeki
önemli erişim ve işlemleri zaman sırasıyla belgeleyen işlem kaydıdır. Site
yönetiminde bu kayıt; bir aidat tutarını kimin güncellediği, bir kullanıcıya
hangi site için yetki verildiği veya bir finans kaydının ne zaman silme
işlemine konu olduğu gibi soruların araştırılmasına yardımcı olur.

Fakat işlem geçmişi tek başına “kim haklı?” sorusunun cevabı değildir.
Kullanıcı hesabı, zaman, kapsam, işlem ve istek bilgisi olayın dijital izini
sağlar; karar, onay, kaynak belge ve görev tanımıyla karşılaştırılmadıkça
işlemin doğru, yetkili veya hukuken geçerli olduğu sonucu çıkarılamaz. Bu
rehber, site yönetiminde bir işlem kaydını nasıl okuyacağınızı ve somut bir
itirazı nasıl inceleyeceğinizi adım adım açıklar.

Audit log nedir ve işlem geçmişinden farkı var mıdır?

NIST’in güncel audit
log sözlüğü, kavramı belirli olaylara ilişkin belgesel kayıt ve sistem
erişimleriyle operasyonları içeren kronolojik sistem faaliyeti kaydı olarak
açıklar. Uygulamada “audit log”, “denetim kaydı”, “işlem kaydı” ve “işlem
geçmişi” ifadeleri birbirine yakın anlamlarda kullanılabilir. Önemli olan
etiket değil, kaydın bir incelemeyi gerçekten destekleyecek bağlamı taşımasıdır.

Her log, audit log değildir. Sunucudaki bir hata mesajı uygulamanın neden
yanıt vermediğini gösterebilir; ancak hangi yöneticinin hangi sitenin hangi
aidat kaydını değiştirdiğini anlatmayabilir. Benzer biçimde son değeri gösteren
bir hareket listesi, önceki değeri veya işlemi başlatan isteği korumuyorsa
denetim sorusunu eksik bırakır.

Kayıt türü	Temel soru	Tek başına neyi göstermez?
İşlem kaydı / audit log	Hangi hesap, ne zaman, hangi kapsamda ne yaptı?	İşlemin neden doğru veya yetkili olduğunu
Teknik uygulama logu	Sistem hangi teknik olayı veya hatayı üretti?	İşlemin yönetim sürecindeki anlamını
Finans hareketi	Tutar hangi hesaba ve döneme işlendi?	Kaydı kimin hangi onayla değiştirdiğini
Karar, tutanak veya onay kaydı	İşlemin yönetimsel dayanağı nedir?	Kararın sistemde nasıl ve ne zaman uygulandığını

Bu kayıtlar birbirinin alternatifi değildir. Yönetimin tutması gereken resmî
ve operasyonel belgelerin ayrımını
apartman ve site yöneticisi kayıt rehberinde görebilirsiniz. Audit log, noter tasdikli karar defterinin, imzanın, faturanın
veya onayın yerine geçmez; bu belgelerin sistemdeki uygulama iziyle
ilişkilendirilmesini kolaylaştırır.

Bir işlem kaydında hangi alanlar bulunmalı?

İnceleme için yalnızca “kayıt güncellendi” satırı çoğu zaman yeterli değildir.
Bir olayın diğer olaylarla ilişkilendirilebilmesi için kullanıcı, zaman,
kapsam, işlem ve istek bilgileri birlikte düşünülmelidir.

1. Kullanıcı: İşlemi hangi hesap yaptı?

Kullanıcı kimliği, işlemi yapan sistem hesabını ve mümkünse o anda geçerli
rolü göstermelidir. Ortak kullanılan “yönetici” hesabı varsa gerçek işlem
sahibini ayırmak zorlaşır. Bununla birlikte bir hesabın görünmesi, o hesabı
fiziksel olarak kimin kullandığını tek başına kesinleştirmez; kimlik doğrulama,
oturum güvenliği ve hesap paylaşımı ayrıca incelenmelidir.

2. Zaman: Olay ne zaman ve hangi sırada gerçekleşti?

Zaman damgası saat dilimiyle birlikte okunmalıdır. Önce yetki verilip sonra mı
kayıt değiştirildi, yoksa değişiklik sırasında rol zaten mevcut muydu? Aynı
dakika içindeki olayların sırası ve sistem saatlerinin uyumu bu nedenle
önemlidir. Ekran görüntüsündeki yerel saat ile dışa aktarılan UTC kaydını
karşılaştırırken dönüşümü belgeleyin.

3. Kapsam: Hangi site, modül ve kayıt etkilendi?

Çoklu site yönetiminde aynı kayıt numarası farklı kapsamda tekrar edebilir.
İşlem satırı; site veya portföy kapsamını, modülü, kayıt türünü ve hedef kaydın
tekil kimliğini taşımalıdır. “Finans kaydı güncellendi” yerine “A Sitesi,
tahakkuk kaydı, kayıt kimliği 458” gibi ilişkilendirilebilir bir kapsam gerekir.

4. İşlem: Ne yapıldı ve hangi sonuç oluştu?

Oluşturma, güncelleme, silme, onay, dışa aktarma ve yetki değişikliği ayrı
olay türleridir. Güncellemede hangi alanların değiştiği ve mümkünse önceki ile
sonraki değerlerin güvenli bir özeti görünmelidir. Ancak sır, parola, kart
bilgisi veya gereksiz kişisel veri “önceki değer” diye loga taşınmamalıdır.

5. İstek: Olaylar hangi işlem zincirine aittir?

İstek ya da işlem numarası, aynı kullanıcı eylemi sırasında oluşan ilgili
kayıtları bir araya getirir. Örneğin bir yetki güncellemesi hem rol atamasını
hem bildirim üretimini hem de oturumların yenilenmesini tetikleyebilir. Ortak
istek numarası, bu olayların bağımsız mı yoksa aynı zincirin parçaları mı
olduğunu anlamaya yardımcı olur.

Örnek vaka: Aidat tutarını kim değiştirdi?

Bir sakin, Eylül dönemi aidatının önce 1.500 TL göründüğünü, daha sonra 1.900
TL’ye çıktığını ve bu değişiklik hakkında bilgi verilmediğini söylüyor. Son
tutara bakmak, değişikliğin kaynağını açıklamaz. Aşağıdaki inceleme akışı,
hafızaya veya tahmine dayanmak yerine kayıtları ilişkilendirir.

Adım 1: İddiayı ve zaman aralığını yazın

İncelenecek bağımsız bölümü, dönemi, önceki ve iddia edilen yeni tutarı,
itirazın geldiği zamanı ve beklenen açıklamayı tek bir olay kaydında toplayın.
“Aidat yanlış” gibi geniş bir başlık yerine araştırılabilir sınır belirleyin.
İnceleme sahibi ve hedef yanıt tarihi de bu aşamada atanmalıdır.

Adım 2: İşlem kaydını kullanıcı, kapsam ve istekle filtreleyin

İlgili dönem ve tahakkuk kaydını seçin. Oluşturma, tutar güncelleme, toplu
işlem, silme/yeniden oluşturma ve onay olaylarını zaman sırasına dizin. Aynı
istek numarasına bağlı olayları gruplayın; işlemi yapan hesabın o anda hangi
rol ve site kapsamına sahip olduğunu ayrıca kontrol edin.

Adım 3: Kaynak karar ve onayla karşılaştırın

Log “finans kullanıcısı tutarı 1.500 TL’den 1.900 TL’ye güncelledi” diyebilir;
fakat bu değişikliğin kurul kararına, onaylı işletme projesine veya geçerli bir
düzeltmeye dayanıp dayanmadığını söylemez. Karar numarası, bütçe kalemi,
onaylayan kişi ve varsa değişiklik gerekçesiyle karşılaştırın. Kayıt ile dayanak
uyuşmuyorsa konu sadece teknik hata değil, süreç ve yetki kontrolü sorunudur.

Adım 4: Bulguyu, düzeltmeyi ve kapanışı kaydedin

Sonuç “kullanıcı hatası” gibi belirsiz bir notla kapanmamalıdır. Hangi kaydın
yanlış olduğu, nasıl düzeltildiği, kim tarafından kontrol edildiği, ilgili
kişiye hangi kanaldan bilgi verildiği ve tekrarını önleyen kural yazılmalıdır.
Düzeltme işlemi de yeni bir audit log olayı üretmeli; eski olay görünmez hale
getirilmemelidir.

İşlem kaydı neyi gösterir, neyi göstermez?

İşlem kaydı destekleyebilir	Tek başına sonuçlandırmaz
İşlemi yapan sistem hesabı ve o andaki rol	Hesabı fiziksel olarak kimin kullandığı
Olay zamanı ve diğer olaylarla sırası	Kullanıcının niyeti veya sözlü talimatı
Etkilenen site, modül ve kayıt	İşlemin yönetim kararıyla uyumu
Oluşturma, güncelleme, silme veya yetki olayı	Değişikliğin hukuken geçerli olup olmadığı
Bir istek içindeki ilişkili olaylar	Kaynak belgenin gerçekliği ve yeterliliği

Bu sınır iki hatayı önler: Log bulununca incelemenin bitmiş sayılması ve log
yoksa işlemin hiç gerçekleşmediğinin varsayılması. Kayıt mekanizması olaydan
sonra devreye alınmış, belirli modülleri kapsamıyor veya teknik kesinti yaşamış
olabilir. İnceleme raporunda log kapsamını ve bilinen boşlukları açıkça yazın.

Site yönetiminde hangi olaylar öncelikli kaydedilmeli?

Her fare hareketini toplamak yerine, finansal sonucu, kişisel veri erişimini,
yetkiyi veya yönetim kararının uygulanmasını etkileyen olayları önceliklendirin.
Başlangıç listesi şu olayları içerebilir:

• Kullanıcı oluşturma, devre dışı bırakma ve yeniden etkinleştirme,
• rol, site kapsamı ve kritik izin değişiklikleri,
• tahakkuk, tahsilat, mahsup ve gider kaydı oluşturma veya düzeltmeleri,
• finansal kaydı silme, iptal etme ya da geriye alma girişimleri,
• toplu veri içe aktarma, dışa aktarma ve rapor indirme,
• sakin, personel veya ziyaretçi kayıtlarında toplu değişiklik,
• duyuru hedef kitlesi ve gönderim ayarı değişiklikleri,
• işlem kayıtlarına erişim ve loglama ayarı değişiklikleri,
• başarısız kritik işlem veya yetkisiz erişim denemeleri.

İzlenecek olaylar rol ve yetki tasarımıyla birlikte belirlenmelidir.
site
yönetiminde yetki matrisi rehberi, hangi rolün hangi site, modül ve işlem
düzeyine erişeceğini çıkarmanıza yardımcı olur. İşlem kaydı gerçekleşen olayı
görünür kılar; yanlış yetkiyi önceden engelleyen kontrolün yerine geçmez.

Denetim kayıtları nasıl korunmalı ve incelenmeli?

Kaydı üreten kullanıcı, geçmişi değiştirememeli

Bir finans kullanıcısı kendi yaptığı işlemi kayıttan kaldırabiliyorsa audit
trail güvenilirliğini kaybeder. Kayıt üretme, kayıt görüntüleme, dışa aktarma,
saklama politikası ve imha yetkilerini ayırın. Silinmezlik de sınırsız saklama
anlamına gelmemelidir; kontrollü saklama ve imha politikası, yetki ve kayıt
iziyle yürütülmelidir.

Log ekranına erişimi de sınırlandırın

İşlem kayıtları kullanıcı adı, IP adresi, kayıt kimliği ve iş bağlamı gibi
bilgiler içerebilir. Her personele bütün logları açmak yerine site, zaman,
olay türü ve görev kapsamına göre erişim verin. İnceleme yapan kişinin ana
kaydı değiştiremeyeceği salt okunur görünüm, görev ayrımını güçlendirebilir.

Düzenli gözden geçirme ve uyarı kuralı kurun

Logları yalnızca şikâyet geldiğinde açmak gecikmiş bir kontroldür. KVKK’nın
Nisan 2025 tarihli
Kişisel Veri Güvenliği Rehberi, kişisel veri güvenliğinin takibi kapsamında kullanıcı işlem hareketlerinin
düzenli tutulmasını, erişim kontrolü kayıtlarının ve raporlama araçlarının
düzenli kontrol edilmesini ele alır. Kurumun yapısına ve riskine göre örneğin
geniş yetki ataması, toplu dışa aktarma veya olağandışı silme denemesi için
uyarı ve inceleme sahibi tanımlanabilir.

Her işlem türü için tek bir saklama süresi varsaymayın

Bütün audit loglar için evrensel bir gün/yıl sayısı yoktur. İşleme amacı,
olayın fark edilme süresi, sözleşme ve mevzuat yükümlülükleri, uyuşmazlık
penceresi, veri niteliği ve sistem riski birlikte değerlendirilmelidir. Süreyi
olay türü bazında belirleyin; aktif arama katmanı, erişim kontrollü arşiv ve
imha adımlarını yazılı hale getirin.

KVKK açısından loglarda hangi veriler bulunmamalı?

“Ne kadar çok veri, o kadar iyi denetim” yaklaşımı güvenli değildir. Audit
kaydı; olayın araştırılması için gerekli kimlik, zaman, kapsam, eylem ve sonuç
bilgilerini taşımalı, işlem gövdesinin tamamını körlemesine kopyalamamalıdır.
Parola, doğrulama kodu, erişim anahtarı, tam kart bilgisi, gereksiz T.C. kimlik
numarası veya mesaj içeriği loga yazılmamalıdır.

KVKK’nın 2023/412
sayılı karar özetinde, bir ihlal incelemesinde GET ve POST isteklerinin
hata loglarına kaydedilmesi nedeniyle kart bilgilerinin açıkta kalmasının
ihlalin boyutunu büyüttüğü değerlendirilmiştir. Bu örnek, log tutmanın gerekli
olabileceğini fakat log içeriğinin veri minimizasyonu ve maskeleme olmadan
ayrı bir risk üretebileceğini gösterir.

İşlem kayıtlarının varlığı KVKK uyumunu tek başına sağlamaz. Hukuki işleme
şartı, aydınlatma, amaçla sınırlılık, yetki yönetimi, güvenlik, saklama ve imha
kontrolleri birlikte değerlendirilmelidir. Somut veri sorumlusu/veri işleyen
rolleri ve alınacak tedbirler için hukuk ve bilgi güvenliği uzmanı görüşü alın.

Liyova işlem kayıtları incelemeyi nasıl destekler?

Liyova İşlem Kayıtları,
kritik finans, veri güncelleme ve yetki işlemlerini kullanıcı, zaman, kapsam,
IP adresi ve istek numarası bağlamında izlemeye yardımcı olur. Bu alanlar,
belirli bir itirazda olayları filtreleyip aynı işlem zincirindeki kayıtları
ilişkilendirmek için kullanılabilir. İşlem kaydı yine kaynak kararın, onayın
veya resmî belgenin yerine geçmez.

Yetki ve Rol
Yönetimi ile rol, izin ve site kapsamı tanımlanabilir; audit log üzerinden
bu yetkilerin ne zaman değiştiği incelenebilir. Önleyici yetki kontrolü ile
sonradan incelemeyi sağlayan işlem izi birbirini tamamlar. Aynı kişinin kendi
rolünü genişletip yaptığı işlemi tek başına onaylamaması için görev ayrımı
ayrıca tasarlanmalıdır.

Liyova Raporlar, finans
ve operasyon görünümünden dikkat gerektiren kayıtları belirlemeye yardımcı
olur. Rapordaki bir sapma tespit edildikten sonra işlem geçmişine geçerek
değişikliğin zamanını ve kapsamını araştırabilirsiniz. Rapor toplamı ve audit
kaydı aynı veri zincirinin farklı sorularını yanıtlar.

Bir site yönetim yazılımını değerlendirirken sorulacak sorular

• Hangi kritik olaylar kaydediliyor, hangileri kapsam dışında kalıyor?
• Kullanıcı, zaman, site kapsamı, hedef kayıt ve istek numarası görülebiliyor mu?
• Değişiklikte önceki ve sonraki değer güvenli biçimde ayrıştırılıyor mu?
• Loglarda sır veya gereksiz kişisel veri tutulması engelleniyor mu?
• Kayıtları kimler görüntüleyebilir, dışa aktarabilir veya imha edebilir?
• Logu üreten kullanıcı kendi işlem geçmişini değiştirebiliyor mu?
• Saat dilimi, sistem saati ve olay sırası anlaşılır mı?
• Yetki değişikliği ile sonraki kritik işlem aynı incelemede ilişkilendirilebiliyor mu?
• Saklama ve kontrollü imha politikası olay türüne göre tanımlanabiliyor mu?
• Bir örnek itiraz baştan sona, kaynak belgeye kadar araştırılabiliyor mu?

Demo sırasında yalnızca işlem geçmişi ekranının varlığını görmeyin. Örnek bir
finans kaydını değiştirin, farklı rolde ikinci kullanıcıyla yetki verin, sonucu
filtreleyin ve kaynak rapora dönün. Bu senaryoyu daha geniş ürün değerlendirmesine
eklemek için
site yönetim
programı seçme rehberindeki akış bazlı demo kontrolünü kullanabilirsiniz.

Sık sorulan sorular

Audit log ile hata logu aynı şey midir?

Hayır. Hata logu teknik arıza ve istisnaları anlamaya odaklanır. Audit log ise
önemli erişim ve işlemlerin kullanıcı, zaman, kapsam ve eylem bağlamını
araştırmaya yardımcı olur. Aynı olay için her iki log türü birlikte
incelenebilir; ancak birbirinin yerine geçmez.

İşlem kaydı bir personelin suçlu olduğunu kanıtlar mı?

Tek başına hayır. Kayıt belirli bir kullanıcı hesabından işlem yapıldığını
gösterebilir; hesabı fiilen kimin kullandığı, yetkinin doğru verilip verilmediği,
talimat, onay ve niyet gibi konular ayrı kanıtlarla değerlendirilmelidir.
Disiplin veya hukukî sonuçlar yetkili uzmanlarca somut olaya göre incelenmelidir.

Audit log kayıtları silinmemeli mi?

Normal kullanıcıların kayıtları değiştirememesi ve olay geçmişinin bütünlüğü
önemlidir. Ancak bu, kişisel veri içerebilecek kayıtların amaçsız ve süresiz
tutulması anlamına gelmez. Yetkili, kayıtlı ve politika temelli bir saklama–imha
süreci tasarlanmalıdır.

IP adresi işlemi yapan kişiyi kesin olarak gösterir mi?

Hayır. IP adresi olay bağlamına katkı sağlayabilir; ancak ortak ağ, VPN, mobil
bağlantı veya proxy nedeniyle tek başına kişiyi kesin biçimde tanımlamaz.
Kullanıcı hesabı, oturum, cihaz ve istek bilgileriyle birlikte, veri
minimizasyonu gözetilerek değerlendirilmelidir.

Küçük apartmanlarda audit log gerekli midir?

İşlem sayısı az olsa da birden fazla kişinin finans veya sakin kayıtlarını
değiştirdiği sistemlerde izlenebilirlik önemlidir. Kontrolün kapsamı yapının
büyüklüğü, veri niteliği, rol sayısı ve riskine göre sadeleştirilebilir; ortak
hesap kullanmak veya geçmişi hiç tutmamak küçük yapı olmanın doğal sonucu
değildir.

Sonuç: İşlem kaydını hüküm değil, inceleme zinciri olarak kullanın

Site yönetiminde audit log; kullanıcıyı, zamanı, kapsamı, işlemi ve istek
zincirini görünür kılar. Değerli olan yalnızca bu alanların bulunması değil,
kaydın kaynak karar, onay, ana veri ve raporla ilişkilendirilebilmesidir.
İnceleme sonucunu ve düzeltici adımı da kayıt altına aldığınızda işlem geçmişi,
şikâyet anında açılan pasif bir ekran olmaktan çıkar ve düzenli iç kontrolün
parçasına dönüşür.

Kendi yönetim modelinizde yetki değişikliği, finansal düzeltme ve kayıt inceleme
senaryolarını görmek için Liyova demo
talebi oluşturabilir; örnek bir işlemi kaynak rapordan audit log kaydına
kadar birlikte değerlendirebilirsiniz.

Bu içerik genel operasyon ve bilgi güvenliği bilgilendirmesidir; hukukî
görüş, delil değerlendirmesi veya kişiye özel KVKK danışmanlığı değildir.
Saklama, erişim, işleme şartı ve olay inceleme süreci somut organizasyon ve
güncel mevzuata göre yetkili uzmanlarla belirlenmelidir.