ERETEK
BİLGİ SİSTEMLERİ

TISAX Düzeltici Eylem Planı: Bulgu Kapatma ve Geçici Etiket

TISAX bulgusu çıktıysa: kabul edilen düzeltici eylem planı satırı, geçici etiket koşulları, gerçekçi hedef tarih ve takip değerlendirmesinde kanıt sunumu.

Bu makalede8 bölüm
Teknik özet
Teknoloji
TISAX, VDA ISA, ENX portalı, düzeltici eylem planı
Konu
TISAX bulgularının düzeltici eylem planı ve geçici etiket süreciyle kapatılması
Seviye
Orta
Ön koşullar
  • Tamamlanmış bir TISAX ilk değerlendirmesi ve bulgu listesi
  • VDA ISA öz değerlendirmesine hâkimiyet

TISAX kapanış toplantısında bulgu çıktıysa sorun bulgunun kendisi değil, ardından yazılan plandır. Zayıf bir düzeltici eylem planını değerlendirme sağlayıcısı geri çevirir; geçici etiket gecikir, müşteriye verilen tarih kaçar. Aşağıda bulgu sınıfının etikete etkisini, sağlayıcının kabul ettiği plan satırının yapısını, geçici etiket koşullarını ve takip değerlendirmesinde kanıtın nasıl sunulacağını bilgi güvenliği sorumluları ve TISAX proje yöneticileri için sahada gördüğümüz hatalar üzerinden anlatıyoruz.

Bulgu türleri ve etikete etkisi

Değerlendirme raporunda her VDA ISA kontrolü için tespit edilen durum, sağlayıcının sınıflandırmasıyla kayda geçer. Etiketin hangi yoldan verileceğini bu sınıf belirler. Tablo genel mantığı gösterir; bağlayıcı tanımlar ENX’in katılımcı el kitabındadır.

Bulgu türü Anlamı Etiket sürecine etkisi
Majör uygunsuzluk Gereklilik sistematik olarak karşılanmıyor ya da koruma hedefi doğrudan tehlikede Geçici etiketi engeller; plan ve takip değerlendirmesi zorunlu
Minör uygunsuzluk Gereklilik kısmen karşılanıyor, tekil veya sınırlı sapma var Kabul edilen planla geçici etiket mümkün; takip değerlendirmesi gerekir
Gözlem Henüz uygunsuzluk değil, risk taşıyan bir eğilim Etiketi engellemez; bir sonraki değerlendirmede bakılır
İyileştirme alanı Gereklilik karşılanıyor, daha iyi uygulanabilir Etkisi yok; öneri niteliğinde

Mantık ISO 27001 belgelendirmesindeki majör–minör ayrımına benzer; fark şu ki TISAX’te bulgu doğrudan etikete ve süreye bağlanır. Genel sınıflandırma ilkeleri için majör ve minör uygunsuzluk farkı yazısına bakın. Sayıya değil, bulgunun hangi etiketle ilişkili olduğuna bakın. Prototip koruma kontrollerindeki tek bir majör bulgu, bilgi güvenliği etiketinin geçici olarak verilmesine engel olmasa bile prototip etiketini bekletebilir.

Sahada en sık gördüğümüz hata, kapanış toplantısında bulgunun ne dediğini tam anlamadan masadan kalkmaktır. Yanlış anlaşılan bulgu yanlış plana dönüşür. Toplantıda her bulgu için “hangi kayıt veya gözlem bu sonuca götürdü?” sorusunu sorun ve yanıtı not alın.

İlk değerlendirmeden kalıcı etikete akış

  1. İlk değerlendirme ve kapanış toplantısı: Sağlayıcı bulguları ve sınıflarını paylaşır. Bulgunun gerekçesini burada netleştirin.
  2. Düzeltici eylem planının sunulması: Her bulgu için kök neden, eylem, sorumlu ve tarih içeren plan sağlayıcıya gider.
  3. Plan değerlendirmesi: Sağlayıcı planın bulguyu gerçekten giderip gidermeyeceğine ve tarihlerin makul olup olmadığına bakar. Gerekirse revizyon ister.
  4. Geçici etiket: Koşullar sağlanırsa ENX portalında geçici etiket yayımlanır ve müşterilerle paylaşılabilir.
  5. Uygulama dönemi: Eylemler hayata geçer, kanıt birikir.
  6. Takip değerlendirmesi: Sağlayıcı eylemlerin uygulandığını ve işe yaradığını doğrular; bulgular kapanırsa kalıcı etiket yayımlanır.

ENX, ilk değerlendirmeden takip değerlendirmesinin bitişine kadar geçebilecek azami bir süre tanımlar; el kitabının bilinen sürümlerinde bu süre dokuz aydır. Süre ve koşullar güncellenebildiği için takvimi kurmadan önce ENX’in güncel dokümanlarını ve ENX portalındaki bilgiyi kontrol edin. Takvim bu süreye göre kurulur. Müşteri tarihine göre değil.

Düzeltici eylem planının içeriği

Sağlayıcı planı ancak her satır bulguyu tek başına anlaşılır kıldığında ve eylemle bulgu arasındaki bağ açıkça göründüğünde kabul eder. “Prosedür güncellenecek” diye biten tek cümlelik satırlar büyük olasılıkla geri döner. Aşağıda erişim yetkileriyle ilgili bir minör bulgu için örnek plan satırı var; kontrol numarasını kullandığınız VDA ISA sürümünden doğrulayın.

Bulgu No      : F-07 (Minör)
ISA kontrolü  : 4.2.1 Erişim hakları yönetimi
Bulgu         : Mühendislik dosya sunucusunda proje klasörü yetkileri
                periyodik olarak gözden geçirilmiyor; ayrılan 2 personelin
                grup üyeliği devam ediyor.
Kök neden     : Gözden geçirme sorumluluğu tanımlanmamış; İK ayrılış
                bildirimi dosya sunucusu yetkilerini kapsamıyor.
Düzeltme      : Ayrılan personelin grup üyelikleri kaldırıldı (tarih, kayıt no).
Düzeltici eylem:
  1. Proje klasörleri için sahip atanması (proje yöneticisi)
  2. Ayrılış iş akışına dosya sunucusu gruplarının eklenmesi
  3. Çeyreklik yetki gözden geçirme kaydının başlatılması
Sorumlu       : BT Altyapı Yöneticisi / Mühendislik Müdürü
Hedef tarih   : Eylem 1-2: 6 hafta, Eylem 3: ilk çeyrek kaydı
Kanıt         : Sahip listesi, güncel iş akışı ekranı ve test kaydı,
                imzalı ilk gözden geçirme raporu
Etkinlik      : İkinci gözden geçirmede ayrılmış personele ait aktif
                üyelik bulunmaması

Bu satırda üç unsur işi görür. Birincisi düzeltme ile düzeltici eylemin ayrılması: iki hesabın kapatılması bulguyu bugün giderir, ama yarın üçüncü bir ayrılan personelde aynı tablo tekrarlanır. İkincisi kök neden: kişiyi değil süreci göstermelidir. “Sistem yöneticisi unuttu” kök neden değildir. Kök neden analizi için DÖF’te kök neden analizi rehberindeki 5 Neden uygulaması TISAX bulgularında da aynen çalışır. Üçüncüsü kanıt tanımı: takipte neyin gösterileceğini plan aşamasında yazmak, sonradan “bu yeterli mi?” tartışmasını baştan keser.

Teknik bulgularda kök nedeni bulmak için konsolda ilk bakılacak yer çoğu zaman yapılandırmanın kendisi değil, değişikliği tetikleyen süreçtir. Örnekteki gibi ayrılan personelin dosya sunucusu grubunda kalması, Active Directory hesabı kapatılsa bile yerel gruplar veya NAS üzerindeki ayrı yetki tabloları İK iş akışına bağlı değilse tekrar eder.

Geçici etiket koşulları

Geçici etiket müşteriye şunu söyler: bulgular biliniyor ve kabul edilmiş bir planla kapatılıyor. Süreli bir sonuçtur. Verilmesi için genel olarak şu koşullar aranır:

  • İlgili etiket kapsamında açık majör uygunsuzluk bulunmaması,
  • Tüm minör uygunsuzluklar için düzeltici eylem planının sunulmuş ve değerlendirme sağlayıcısınca kabul edilmiş olması,
  • Plan tarihlerinin TISAX sürecinin azami süresi içinde kalması.

Majör uygunsuzlukta ENX el kitabı ayrı bir yol tanımlar: riski geçici olarak azaltan (geçici veya telafi edici) önlemler uygulanır ve sağlayıcı kabul ederse bulgu minöre düşürülebilir. Prototip alanında kartlı geçiş sistemi eksikse, sistem kurulana kadar kayıt tutan güvenlik görevlisi böyle bir önlem olabilir. Geçici önlem kalıcı eylemin yerini tutmaz. Plan ikisini birden içermelidir.

Uygulama süresini planlamak

En sık yapılan planlama hatası, eylem süresini teknik iş yüküne göre değil, istenen etiket tarihinden geriye sayarak yazmaktır. Gerçekçi süre satın almayı, değişiklik onayını, uygulamayı ve en az bir işletim döngüsünün kanıtını kapsar. Aşağıdaki tablo tipik eylem türlerinde süreyi neyin belirlediğini ve kanıtın ne zaman olgunlaştığını gösterir; süreler kuruluşa göre değişir.

Eylem türü Süreyi belirleyen etkenler Kanıt olgunlaşması
Doküman/rol tanımı Hazırlık ve yönetim onayı Onaylı sürüm, duyuru kaydı
Periyodik kontrol başlatma İlk döngünün tamamlanması En az bir dolu kayıt
Teknik yapılandırma Değişiklik onayı, test, bakım penceresi Yapılandırma raporu, test sonucu
Fiziksel düzenleme Satın alma, montaj, yetkilendirme Yerinde gözlem, erişim kayıtları
Tedarikçi sözleşmesi Karşı tarafın hukuki onayı İmzalı sözleşme veya ek protokol

Örnek hesap: satın alma altı hafta, montaj iki hafta, erişim kayıtlarının birikmesi dört hafta. Bu fiziksel güvenlik eylemi yaklaşık üç aylık bir hedef tarih ister. Aynı plandaki doküman eylemlerini bu tarihe bağlamak yerine öne çekin; takipte kapanmış bulgu sayısı artar. Takibi tek seferde yaptırmak istiyorsanız tüm eylemlerin hedef tarihlerini tek bir kanıt teslim tarihinin öncesine toplayın.

Teknik yapılandırma eylemlerinde bakım penceresini plana baştan yazın. Firewall kuralı veya yetki modeli değişikliği, üretim hattının durabileceği tek bir hafta sonuna sıkışıyorsa o tarih kaçarsa bütün plan kayar. Tarih tampon ister.

Takip değerlendirmesi ve kanıt sunumu

Takipte sağlayıcı iki soruya yanıt arar: eylem uygulandı mı, bulgunun nedeni ortadan kalktı mı? İlkini doküman ve yapılandırma kanıtı, ikincisini işletim kaydı yanıtlar. Yöntemi değerlendirme seviyesi etkiler: AL2’de kanıtın çoğu uzaktan incelenebilir, AL3 kapsamındaki fiziksel ve prototip bulguları ise genellikle yerinde görülmek ister. Seviyeler arasındaki yöntem farkı TISAX AL1, AL2 ve AL3 farkları yazısında anlatılıyor.

Kanıt paketini bulgu numarasına göre dizin: her bulgu için plan satırı, kök neden özeti, uygulanan eylemler, kanıt dosyaları ve etkinlik göstergesi. Ekran görüntüsü yerine tarihli sistem raporu, imzasız taslak yerine onaylı sürüm koyun. Bir PowerShell veya sistem çıktısı sunuyorsanız komutun çalıştırıldığı tarih ve sunucu adı çıktıda görünsün. Gönderilecek belgenin gizlilik sınıfına bakın; prototip verisi içeren bir belgenin tamamını göndermek yerine ilgili bölümü maskeleyerek sunabilirsiniz.

Takip öncesinde ilk değerlendirmede gözlem olarak not edilen konuları da gözden geçirin. Bunlar takipte bulguya dönüşmez, ama yeniden değerlendirmede ilk bakılacak yerlerdir. Bulguların olgunluk seviyesine nasıl yansıdığı için VDA ISA olgunluk seviyeleri yazısı tamamlayıcıdır.

Sık yapılan hatalar

  • Bulguyu tersine çevirip eylem diye yazmak: “Yetkiler gözden geçirilecek” bulgunun tersidir, eylem değildir.
  • Kök neden alanını boş bırakmak: Sağlayıcı, nedeni bilinmeyen bir sorunun kalıcı çözüleceğine ikna olmaz.
  • Bütün satırlarda aynı isim: Her satırda bilgi güvenliği sorumlusunun adı geçiyorsa sağlayıcı kapasiteyi sorgular.
  • Geçici önlemi kalıcı çözüm gibi sunmak: Telafi edici önlem bir ara çözümdür; kalıcı eylem ve tarihi ayrıca yazılmalıdır.
  • Kanıtı son haftaya bırakmak: Periyodik kontrolün kaydı zamanla oluşur. Son hafta toplanan kanıt etkinliği göstermez.
  • Diğer lokasyonları unutmak: Bir lokasyonda düzeltilen süreç diğerlerinde de aynı şekilde işliyorsa yaygınlaştırma plana girmelidir.

Kök neden analizi ve kanıt yapısı için denetim sonrası uygunsuzluk kapatma ve DÖF danışmanlığı, değerlendirme sürecinin bütünü için TISAX danışmanlığı ve değerlendirme hazırlığı hizmetlerimize bakabilirsiniz.

Sık sorulan sorular

Majör uygunsuzluk varken geçici etiket alınabilir mi?

Kural olarak hayır. Geçici etiket yalnız minör uygunsuzluklar kaldığında ve düzeltici eylem planı kabul edildiğinde verilir. ENX katılımcı el kitabı, kabul edilen geçici önlemlerle majör bulgunun minöre düşürülebileceği bir yol tanımlar; koşulları güncel el kitabından ve değerlendirme sağlayıcınızdan doğrulayın.

Geçici etiket müşteri için kalıcı etiketle aynı değerde mi?

Geçici etiket ENX portalında paylaşılabilir ve birçok müşteri bunu geçerli kabul eder; ancak süreli olduğu ve takip değerlendirmesine bağlı olduğu görünür. Müşterinizin geçici etiketi sözleşme açısından kabul edip etmediğini önceden sorun.

Takip değerlendirmesi her zaman yerinde mi yapılır?

Hayır. Yöntemi değerlendirme seviyesi ve bulgunun niteliği belirler. Doküman ve kayıtla kapanabilen bulgular uzaktan doğrulanabilir; fiziksel güvenlik veya prototip alanına ilişkin bulgular, özellikle AL3 kapsamında, çoğunlukla yerinde görülmek ister.

Planda verdiğimiz tarihi kaçırırsak ne olur?

Plan tarihi sizin taahhüdünüzdür; sağlayıcı takip değerlendirmesini buna göre planlar. Gecikmeyi fark ettiğiniz anda sağlayıcıya bildirin. Takip, TISAX sürecinin azami süresi içinde tamamlanamazsa geçici etiketin ve değerlendirme sonucunun geçerliliği risk altına girer; sonuçlarını güncel el kitabından ve sağlayıcınızdan doğrulayın. Tarihleri gerçek kapasiteye göre verin.

Teknik özet
Teknoloji
TISAX, VDA ISA, ENX portalı, düzeltici eylem planı
Konu
TISAX bulgularının düzeltici eylem planı ve geçici etiket süreciyle kapatılması
Seviye
Orta
Ön koşullar
  • Tamamlanmış bir TISAX ilk değerlendirmesi ve bulgu listesi
  • VDA ISA öz değerlendirmesine hâkimiyet
Eretek uzman desteği

Bu konuyu kendi ortamınızda birlikte ele alalım.

Mevcut yapınızı inceliyor, eksikleri önceliklendiriyor ve uygulanabilir bir plan çıkarıyoruz.