Bir gözetim denetiminde denetçi, iki yıl önce yürürlükten kalkmış bir kaynak talimatının o dönemki hâlini görmek istedi. Sistemde arattık, kayıt yoktu. Bir kullanıcı, arşivi "temizlerken" eski revizyonları tek tek silmişti. Kim, hangi tarihte, hangi yetkiyle sildi? Bunu gösteren tek bir satır bile bulamadık. O denetimde aldığımız bulgu doküman kontrolüyle ilgiliydi ama asıl sorun oradaki değildi: kalite yazılımı veri güvenliği üç ayaklı bir yapıdır ve bizde üçünden ikisi eksikti.
Üç sorunun cevabı yoksa sistem güvenli değil
Kalite sisteminde veri güvenliği, kimin neye erişebildiği, kimin ne yaptığı ve veri kaybolduğunda nasıl geri geleceği sorularının cevabıdır. Bu üçü sırasıyla yetkilendirme, işlem logu ve yedeklemedir. Üçü de kurulmadıkça, üzerine ne kadar güvenlik duvarı ve şifre politikası koyarsanız koyun, denetimde ayakta duran bir yapı elde edemezsiniz.
Bu bir bilgi işlem konusu gibi görünse de kalite biriminin işidir. Çünkü yetki matrisini hazırlayan, hangi işlemin loglanması gerektiğine karar veren ve yedeğin gerçekten geri döndüğünü kanıtlayan tatbikatı yürüten kişi kalite tarafındadır. Bilgi işlem altyapıyı kurar; kuralı siz koyarsınız. Kalite yazılımı veri güvenliği bu yüzden ortak bir sorumluluktur.
Rol bazlı yetkilendirme: kişiye değil göreve tanımlayın
Yetkilendirmede yapılan en yaygın hata, yetkileri tek tek kişilere vermektir. Ayşe Hanım doküman yayınlasın, Murat Bey DÖF kapatsın derken üç yıl sonra elinizde kimin neye eriştiği bilinmeyen bir liste kalır. Doğrusu rol tanımlamaktır: Doküman Sorumlusu, Kalite Mühendisi, Süreç Sahibi, İç Denetçi, Okuyucu. Yetkiyi role verir, kişiyi role atarsınız. Personel değiştiğinde tek yaptığınız atamayı güncellemektir.
Aşağıdaki matris, otomotiv tedarikçisi bir firmada doküman ve DÖF süreçleri için işleyen bir yetki dağılımını gösteriyor. Kolon başlıklarını kendi sisteminizin işlem adlarıyla değiştirin; mantık aynı kalır.
| Rol | Okuma | Oluşturma | Onaylama | Yayınlama | Pasife alma | Yetki değiştirme |
|---|---|---|---|---|---|---|
| Okuyucu (operatör, ustabaşı) | Kendi bölümü | Yok | Yok | Yok | Yok | Yok |
| Süreç sahibi | Kendi süreci | Var | Kendi süreci | Yok | Yok | Yok |
| Kalite mühendisi | Tümü | Var | Var | Yok | Yok | Yok |
| Doküman sorumlusu | Tümü | Var | Yok | Var | Var | Yok |
| Kalite yöneticisi | Tümü | Var | Var | Var | Var | Yok |
| Sistem yöneticisi | Tümü | Yok | Yok | Yok | Yok | Var |
Tablodaki en önemli satır sonuncusudur. Sistem yöneticisi yetki verir ama kalite kaydı oluşturmaz, onaylamaz ve yayınlamaz. Görevler ayrılmadığında, yetkiyi kendine verip kaydı da kendi onaylayabilen bir kullanıcı ortaya çıkar. Bu, iç kontrol açısından kabul edilemez bir durumdur ve denetimde hemen sorulur.
Yetki matrisi kim tarafından onaylanır
Yetki matrisi bir dokümandır ve diğer prosedürleriniz gibi onaylanmalı, revizyon numarası taşımalı ve gözden geçirilmelidir. Onay kalite yöneticisinde, uygulama bilgi işlemdedir. Gözden geçirme sıklığı için yılda bir yeterlidir; ama iki durumda beklemeyin: personel ayrılışlarında ve organizasyon değişikliklerinde. İşten ayrılan bir kullanıcının hesabı, ayrılış tarihinden itibaren en geç bir iş günü içinde pasife alınmalıdır.
Yılda bir yapılan gözden geçirmede işe yarayan bir yöntem var: sistemden aktif kullanıcı ve rol listesini dökün, insan kaynakları bordro listesiyle karşılaştırın. Her yıl bu karşılaştırmadan iki üç sürpriz çıkar — ayrılmış personelin açık hesabı, stajyer için açılıp kapatılmamış yetki, geçici olarak verilip unutulmuş yönetici rolü. Bu karşılaştırma tutanağı, ISO/IEC 27001:2022 ekindeki erişim kontrolü maddesinin de beklediği kanıttır.
Yetkilendirmeyi tek hamlede çökerten şey ortak kullanıcı hesabıdır. Hat başındaki tablet için "uretim1" diye bir hesap açılır, şifre herkes tarafından bilinir, okundu teyitleri o hesaptan verilir. O andan sonra logunuz da anlamsızlaşır, çünkü kaydın altında gerçek bir kişi yoktur. Operatörlere kişisel hesap açmak zahmetlidir ama alternatifi, denetimde savunulamayacak bir kayıt yığınıdır.
İşlem logu: neyi, hangi ayrıntıda tutmalı
İşlem logu (audit trail) kalite sisteminin hafızasıdır. Asgari olarak şunlar kaydedilmelidir: oturum açma ve başarısız giriş denemeleri, kayıt oluşturma ve güncelleme, doküman yayınlama ve yürürlükten kaldırma, onay ve ret işlemleri, yetki değişiklikleri, dosya eki ekleme ve kaldırma, veri dışa aktarma. Her satırda kullanıcı, tarih-saat, işlem türü ve değişen alanın eski-yeni değeri bulunmalıdır.
Son madde çoğu sistemde eksik kalır. Yalnızca "kayıt güncellendi" yazan bir log, denetimde hiçbir soruyu cevaplamaz. Denetçi bir kontrol planında toleransın ne zaman ve kim tarafından değiştirildiğini sorduğunda, eski değer ile yeni değeri yan yana görmek ister. Log kayıtlarının kendisi de değiştirilemez olmalı; sistem yöneticisi dâhil hiç kimse log satırını düzenleyememelidir.
Log saklama süresi için pratik bir kural: kaydın kendisinin saklama süresi ne ise logu da o kadar saklayın. Doküman yönetimi tarafında bu süre genelde yürürlükten kalkma tarihinden itibaren tanımlanır; PPAP ve izlenebilirlik kayıtlarında ise ürün ömrü artı bir yıl beklentisi geçerlidir.
ISO 9001 madde 7.5.3.2 dokümante bilginin (documented information) dağıtımını, erişimini, saklanmasını, değişikliklerinin kontrolünü ve elden çıkarılmasını ister. Denetçi bunu tek bir soruyla test eder: "Bu prosedürün bir önceki revizyonunu gösterin ve o revizyonu kimin, ne zaman yürürlükten kaldırdığını söyleyin." Bu soruya bir ekran görüntüsüyle cevap veremiyorsanız, maddenin değişiklik kontrolü kısmını karşılamıyorsunuz demektir.
Aynı disiplini diğer modüllerde de kurun. DÖF kapatma, kalibrasyon sonucu girme, tedarikçi karnesi onaylama ve ölçüm sonucu düzeltme işlemleri de aynı log ayrıntısını hak eder. Kalite verisi içinde sonradan en çok değiştirilmeye çalışılan alanlar bunlardır.
Logu okumayan log işe yaramaz
Log tutmak yetmiyor; kimsenin bakmadığı bir log, olay yaşandıktan sonra açılan bir arşivden ibaret kalıyor. Ayda bir, on beş dakikalık basit bir gözden geçirme yeterli. Bakılacak dört şey var: mesai dışı saatlerde yapılan yayınlama işlemleri, aynı kullanıcıdan gelen üst üste başarısız giriş denemeleri, yetki değişikliği kayıtları ve olağan dışı büyüklükteki veri dışa aktarmaları. Bu dördü, kalite verisiyle ilgili sorunların büyük kısmını erken yakalar.
Gözden geçirmeyi kim yapacak sorusunun cevabı da net olmalı. Sistem yöneticisinin kendi işlemlerini kendisinin denetlemesi anlamlı değildir; bu kontrolü kalite yöneticisi ya da atanmış bir iç denetçi yapar. Aylık kontrol kaydını kısa bir formla tutun; denetimde istendiğinde çıkaracağınız kanıt budur.
Silme diye bir işlem olmamalı
Yayınlanmış hiçbir kalite kaydı veritabanından fiziksel olarak silinmemelidir. Doğru yaklaşım pasife almadır: kayıt veritabanında kalır, arayüzde kullanılamaz hâle gelir, kim tarafından ne zaman pasife alındığı loglanır. Böylece hem geçmişe dönük izlenebilirlik korunur hem de yanlışlıkla yapılan bir işlem geri alınabilir. Yazılım seçerken bu davranışı demo sırasında bizzat test edin: bir kaydı silmeye çalışın, sistem ne yapıyor?
Fiziksel silme yetkisi yalnızca tek bir durumda kullanılmalıdır: saklama süresi dolan kayıtların planlı imhası. Bu da bir imha listesi ve imha tutanağıyla yürütülür, tek bir kullanıcının anlık kararıyla değil. İmha kararının kim tarafından onaylandığı da kayıt altına alınır.
Elektronik onay ve kimlik doğrulama
Kalite kaydının altındaki onayın kime ait olduğunu kanıtlamak, yetkilendirmenin devamıdır. Bir doküman onayı sisteme yalnızca "onaylandı" olarak düşüyorsa ve onay anında kullanıcıdan kimlik doğrulaması istenmiyorsa, açık bırakılmış bir ekran başında herkes o onayı verebilir. Kritik işlemlerde — doküman yayınlama, DÖF kapatma, PPAP onayı — onay anında şifrenin tekrar sorulması küçük bir zahmet ama büyük bir fark yaratır.
Oturum politikası da aynı başlığın parçası. Hat başındaki ortak kullanılan bir bilgisayarda oturumun 10 dakikada, ofis bilgisayarında 30 dakikada kapanması makul bir ayardır. Bunu sistem üzerinde tanımlayamıyorsanız, en azından işletim sistemi tarafında ekran kilidi politikasıyla sağlayın. Bu ayarları prosedüre yazın; sözlü kural birkaç ay içinde unutuluyor.
Kalite yazılımı veri güvenliğinin üçüncü ayağı: yedekleme planı
Yedekleme planını iki sayı belirler. Birincisi kabul edilebilir veri kaybı süresi: sistem çöktüğünde en fazla kaç saatlik veriyi kaybetmeyi göze alabilirsiniz? İkincisi kabul edilebilir kesinti süresi: sistemin en geç kaç saat içinde tekrar ayakta olması gerekir? Kalite sistemleri için sahada oturan değerler genelde dört saat veri kaybı ve sekiz saat kesintidir. Bu iki sayıyı yönetimle birlikte belirleyin ve yedekleme prosedürüne yazın.
Bu değerlere ulaşan asgari kurgu şudur: günde bir kez tam yedek, gün içinde saat başı işlem günlüğü yedeği, yedeklerin en az bir kopyasının farklı bir binada ya da yangın bölmesinde tutulması ve bir kopyanın çevrimdışı olması. Son madde fidye yazılımı riskine karşıdır; ağa bağlı duran bir yedek, saldırı anında ana veriyle birlikte şifrelenir. Sunucunun nerede durduğu kararının etkilerini on-premise kurulum yazımızda ayrıca ele aldık.
Yedeğin nereye yazıldığı kadar kimin eriştiği de önemli. Yedek dosyalarına erişebilen hesap sayısı iki kişiyi geçmemeli, dosyalar şifreli tutulmalı ve bu hesapların günlük işlerde kullanılan hesaplardan ayrı olması gerekir. Kalite verisinin tamamı o dosyanın içindedir; ana sistemde kurduğunuz bütün yetki yapısı, korumasız duran bir yedek dosyasıyla anlamsızlaşır.
Yedek geri dönmeden yedek sayılmaz
Yedekleme işinin en çok atlanan kısmı budur. Yedek alınıyor olması, o yedeğin geri döneceğini göstermez. Yılda en az iki kez tatbikat yapın: üretim dışı bir sunucuya son yedeği geri yükleyin, sistemi açın, rastgele beş kaydı orijinaliyle karşılaştırın. Tutanağa şunları yazın — tatbikat tarihi, geri yüklenen yedeğin tarihi, başlangıç ve bitiş saati, doğrulanan kayıtlar, tespit edilen sorunlar.
Bu tutanak denetimde yedekleme sorusunun tek geçerli cevabıdır. "Yedek alıyoruz" cümlesi kanıt değildir; "son tatbikatı 14 Mart'ta yaptık, 2 saat 40 dakikada geri döndük" cümlesi kanıttır. Tatbikatı ayrıca risk yönetimi kayıtlarınıza da bağlayın; sistem kaybı, kalite risk kaydınızda yer alması gereken bir maddedir.
PaKalite şirket içi kurulduğu için yedekleme ve geri dönüş tatbikatı doğrudan sizin kontrolünüzde yürür; yetki matrisi rol bazlıdır ve kayıtlar silinmez, pasife alınır. Ama kurduğunuz sistem hangisi olursa olsun, bu yazıdaki üç ayağın da yazılı bir prosedürü ve son bir yıl içinde üretilmiş kanıtı olsun. Kalite yazılımı veri güvenliği, yazılan prosedürle değil üretilen kanıtla ölçülür. Denetçinin sorduğu şey yazılımın markası değil, o kanıtın kendisidir.