İşletmelere uçtan uca teknoloji çözümleri+90 538 480 36 29
Siber Güvenlik

Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü

Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü: hesap ve oturumlar, cihaz ve veri ve MFA ve token için ölçülebilir seçim, uygulama ve kontrol rehberi.

Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü teknik rehber kapak görseli
Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü için proje ve teklif öncesi doğrulanması gereken başlıklar.
Kısa cevap

Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü

Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü: hesap ve oturumlar, cihaz ve veri ve MFA ve token için ölçülebilir seçim, uygulama ve kontrol rehberi.

Aynı ürün iki farklı işletmede bütünüyle farklı sonuç verebilir; çünkü yük, fiziksel ortam, kullanıcı davranışı ve risk aynı değildir.

Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü araştırılırken internetteki ürün listeleri ve kısa tanımlar başlangıç için yararlı olabilir; ancak gerçek karar sahadaki koşullar, risk seviyesi ve işletmenin kesintiye tahammülü üzerinden verilmelidir. Bu rehber satış söylemi üretmek için değil, ihtiyaç sahibinin teklifleri aynı ölçekte karşılaştırabilmesi ve kurulum sonunda neyi teslim aldığını anlayabilmesi için hazırlanmıştır.

Hızlı cevap

Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü için doğru yaklaşım; hesap ve oturumlar, cihaz ve veri ve MFA ve token başlıklarını aynı keşif dosyasında toplamak, uygulanabilir iki seçenek çıkarmak ve seçilen seçeneği ölçülebilir kabul kriterleriyle sınamaktır. En ucuz ürün, en yüksek model veya en uzun özellik listesi tek başına doğru çözümü göstermez. İşletme maliyeti, yönetilebilirlik, güvenlik güncellemeleri ve arıza anındaki geri dönüş yolu birlikte düşünülmelidir.

Bu rehberin kapsamı ve varsayımları

Anlatım, küçük ofisten çok şubeli yapılara kadar kurumsal kullanım içindir. Ev kullanımı, yalnızca ürün kutusu açma adımları veya marka bağımsız kesin performans vaadi kapsam dışındadır. Ürün sürümü, lisans paketi, fiziksel ortam ve servis koşulları değişebildiği için son karar öncesinde güncel üretici dokümanı ile teklif eki karşılaştırılmalıdır.

Siber güvenlik kontrolü ürün listesinden değil varlık, tehdit, zafiyet, iş etkisi ve müdahale kapasitesinden başlamalıdır.

Karardan önce hazırlanması gereken veri

İlk görüşmeye yalnızca “fiyat almak istiyorum” cümlesiyle başlanırsa teklif veren firmalar farklı varsayımlar kurar. Biri kablolamayı, diğeri lisansı, üçüncüsü kurulumu hariç tutabilir. Sağlıklı keşif dosyasında mevcut cihaz ve yazılım envanteri, kullanıcı sayısı, kritik süreçler, beklenen büyüme, çalışma saatleri, geçmiş arızalar ve sorumlu kişiler bulunmalıdır.

Hesap ve oturumlar

hesap ve oturumlar, “var” veya “yok” diye işaretlenecek bir özellik değildir. Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü kapsamında önce mevcut değer, yük veya risk belirlenir; daha sonra kabul edilecek hedef yazılır. Ölçümün ne zaman, hangi araçla ve hangi sorumlu tarafından yapıldığı bilinmiyorsa iki teklif arasında sağlıklı karşılaştırma kurulamaz.

Nasıl doğrulanır?

Bu başlık için temel kanıt kimlik/yetki raporu olmalıdır. Sonucun ekran görüntüsüyle sınırlı kalmaması; tarih, kapsam, kullanılan yöntem ve istisnalarla birlikte proje dosyasına eklenmesi gerekir. Normal çalışma koşulunun yanında yoğunluk, bağlantı kaybı, enerji kesintisi veya yetkisiz erişim gibi olumsuz senaryolar da denenmelidir.

Sahada en sık görülen hata

Tatbikat yapılmadan yazılan olay planı baskı altında çalışmayabilir. Bu hata çoğu zaman ilk gün fark edilmez; kullanıcı veya cihaz sayısı arttığında, lisans sona erdiğinde ya da gerçek bir olay yaşandığında görünür hâle gelir. Bu nedenle teslim kabulü yalnızca “sistem açıldı” kontrolüne indirgenmemelidir.

Uygulanabilir karar

Kararı cihaz adedinden önce iş akışı, risk ve büyüme senaryosu üzerinden verin. Teklifte sorumlu taraf, teslim belgesi, bakım aralığı ve geri dönüş adımı açıkça yazılmalıdır. Böylece hesap ve oturumlar için verilen karar satış anındaki varsayıma değil, sonradan denetlenebilir bir kayda dayanır.

Cihaz ve veri

cihaz ve veri, “var” veya “yok” diye işaretlenecek bir özellik değildir. Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü kapsamında önce mevcut değer, yük veya risk belirlenir; daha sonra kabul edilecek hedef yazılır. Ölçümün ne zaman, hangi araçla ve hangi sorumlu tarafından yapıldığı bilinmiyorsa iki teklif arasında sağlıklı karşılaştırma kurulamaz.

Nasıl doğrulanır?

Bu başlık için temel kanıt olay zaman çizgisi ve tatbikat sonucu olmalıdır. Sonucun ekran görüntüsüyle sınırlı kalmaması; tarih, kapsam, kullanılan yöntem ve istisnalarla birlikte proje dosyasına eklenmesi gerekir. Normal çalışma koşulunun yanında yoğunluk, bağlantı kaybı, enerji kesintisi veya yetkisiz erişim gibi olumsuz senaryolar da denenmelidir.

Sahada en sık görülen hata

Tedarikçi erişimini süre ve kayıt olmadan açmak denetim izini bozar. Bu hata çoğu zaman ilk gün fark edilmez; kullanıcı veya cihaz sayısı arttığında, lisans sona erdiğinde ya da gerçek bir olay yaşandığında görünür hâle gelir. Bu nedenle teslim kabulü yalnızca “sistem açıldı” kontrolüne indirgenmemelidir.

Uygulanabilir karar

Önce hedefi tek cümleyle yazın, ardından bu hedefi kanıtlayacak ölçümü belirleyin. Teklifte sorumlu taraf, teslim belgesi, bakım aralığı ve geri dönüş adımı açıkça yazılmalıdır. Böylece cihaz ve veri için verilen karar satış anındaki varsayıma değil, sonradan denetlenebilir bir kayda dayanır.

MFA ve token

MFA ve token, “var” veya “yok” diye işaretlenecek bir özellik değildir. Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü kapsamında önce mevcut değer, yük veya risk belirlenir; daha sonra kabul edilecek hedef yazılır. Ölçümün ne zaman, hangi araçla ve hangi sorumlu tarafından yapıldığı bilinmiyorsa iki teklif arasında sağlıklı karşılaştırma kurulamaz.

Nasıl doğrulanır?

Bu başlık için temel kanıt iyileştirme kapanış kaydı olmalıdır. Sonucun ekran görüntüsüyle sınırlı kalmaması; tarih, kapsam, kullanılan yöntem ve istisnalarla birlikte proje dosyasına eklenmesi gerekir. Normal çalışma koşulunun yanında yoğunluk, bağlantı kaybı, enerji kesintisi veya yetkisiz erişim gibi olumsuz senaryolar da denenmelidir.

Sahada en sık görülen hata

Eski kullanıcı ve servis hesaplarını kapatmamak kalıcı erişim yolu bırakır. Bu hata çoğu zaman ilk gün fark edilmez; kullanıcı veya cihaz sayısı arttığında, lisans sona erdiğinde ya da gerçek bir olay yaşandığında görünür hâle gelir. Bu nedenle teslim kabulü yalnızca “sistem açıldı” kontrolüne indirgenmemelidir.

Uygulanabilir karar

Pilot uygulama mümkünse değişikliği sınırlı alanda doğrulayıp ölçümden sonra yaygınlaştırın. Teklifte sorumlu taraf, teslim belgesi, bakım aralığı ve geri dönüş adımı açıkça yazılmalıdır. Böylece MFA ve token için verilen karar satış anındaki varsayıma değil, sonradan denetlenebilir bir kayda dayanır.

Paylaşılan erişimler

paylaşılan erişimler, “var” veya “yok” diye işaretlenecek bir özellik değildir. Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü kapsamında önce mevcut değer, yük veya risk belirlenir; daha sonra kabul edilecek hedef yazılır. Ölçümün ne zaman, hangi araçla ve hangi sorumlu tarafından yapıldığı bilinmiyorsa iki teklif arasında sağlıklı karşılaştırma kurulamaz.

Nasıl doğrulanır?

Bu başlık için temel kanıt varlık ve veri akışı envanteri olmalıdır. Sonucun ekran görüntüsüyle sınırlı kalmaması; tarih, kapsam, kullanılan yöntem ve istisnalarla birlikte proje dosyasına eklenmesi gerekir. Normal çalışma koşulunun yanında yoğunluk, bağlantı kaybı, enerji kesintisi veya yetkisiz erişim gibi olumsuz senaryolar da denenmelidir.

Sahada en sık görülen hata

Yamayı yalnızca işletim sistemiyle sınırlamak ağ cihazı ve üçüncü taraf uygulamaları açık bırakır. Bu hata çoğu zaman ilk gün fark edilmez; kullanıcı veya cihaz sayısı arttığında, lisans sona erdiğinde ya da gerçek bir olay yaşandığında görünür hâle gelir. Bu nedenle teslim kabulü yalnızca “sistem açıldı” kontrolüne indirgenmemelidir.

Uygulanabilir karar

Birincil çözümün yanında geri dönüş planını ve kabul edilmeyecek sınırı da tanımlayın. Teklifte sorumlu taraf, teslim belgesi, bakım aralığı ve geri dönüş adımı açıkça yazılmalıdır. Böylece paylaşılan erişimler için verilen karar satış anındaki varsayıma değil, sonradan denetlenebilir bir kayda dayanır.

Tedarikçi ve bulut hesapları

tedarikçi ve bulut hesapları, “var” veya “yok” diye işaretlenecek bir özellik değildir. Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü kapsamında önce mevcut değer, yük veya risk belirlenir; daha sonra kabul edilecek hedef yazılır. Ölçümün ne zaman, hangi araçla ve hangi sorumlu tarafından yapıldığı bilinmiyorsa iki teklif arasında sağlıklı karşılaştırma kurulamaz.

Nasıl doğrulanır?

Bu başlık için temel kanıt risk kaydı ve kontrol kanıtı olmalıdır. Sonucun ekran görüntüsüyle sınırlı kalmaması; tarih, kapsam, kullanılan yöntem ve istisnalarla birlikte proje dosyasına eklenmesi gerekir. Normal çalışma koşulunun yanında yoğunluk, bağlantı kaybı, enerji kesintisi veya yetkisiz erişim gibi olumsuz senaryolar da denenmelidir.

Sahada en sık görülen hata

Kritik verinin sahibini belirlemeden kontrol satın almak gerçek riski çözmez. Bu hata çoğu zaman ilk gün fark edilmez; kullanıcı veya cihaz sayısı arttığında, lisans sona erdiğinde ya da gerçek bir olay yaşandığında görünür hâle gelir. Bu nedenle teslim kabulü yalnızca “sistem açıldı” kontrolüne indirgenmemelidir.

Uygulanabilir karar

Teslim sırasında yapılandırma özeti, yedek ve sorumlu listesini aynı dosyada toplayın. Teklifte sorumlu taraf, teslim belgesi, bakım aralığı ve geri dönüş adımı açıkça yazılmalıdır. Böylece tedarikçi ve bulut hesapları için verilen karar satış anındaki varsayıma değil, sonradan denetlenebilir bir kayda dayanır.

Denetim kanıtı

denetim kanıtı, “var” veya “yok” diye işaretlenecek bir özellik değildir. Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü kapsamında önce mevcut değer, yük veya risk belirlenir; daha sonra kabul edilecek hedef yazılır. Ölçümün ne zaman, hangi araçla ve hangi sorumlu tarafından yapıldığı bilinmiyorsa iki teklif arasında sağlıklı karşılaştırma kurulamaz.

Nasıl doğrulanır?

Bu başlık için temel kanıt kimlik/yetki raporu olmalıdır. Sonucun ekran görüntüsüyle sınırlı kalmaması; tarih, kapsam, kullanılan yöntem ve istisnalarla birlikte proje dosyasına eklenmesi gerekir. Normal çalışma koşulunun yanında yoğunluk, bağlantı kaybı, enerji kesintisi veya yetkisiz erişim gibi olumsuz senaryolar da denenmelidir.

Sahada en sık görülen hata

Tatbikat yapılmadan yazılan olay planı baskı altında çalışmayabilir. Bu hata çoğu zaman ilk gün fark edilmez; kullanıcı veya cihaz sayısı arttığında, lisans sona erdiğinde ya da gerçek bir olay yaşandığında görünür hâle gelir. Bu nedenle teslim kabulü yalnızca “sistem açıldı” kontrolüne indirgenmemelidir.

Uygulanabilir karar

Kararı cihaz adedinden önce iş akışı, risk ve büyüme senaryosu üzerinden verin. Teklifte sorumlu taraf, teslim belgesi, bakım aralığı ve geri dönüş adımı açıkça yazılmalıdır. Böylece denetim kanıtı için verilen karar satış anındaki varsayıma değil, sonradan denetlenebilir bir kayda dayanır.

Uygulama sırası

1. Varlık ve veri akışını çıkar: kritik sistem ve verinin sahibini yazın

2. Tehdit ve iş etkisini puanla: olasılık ile iş etkisini ayrı değerlendirin

3. Mevcut kontrollerin kanıtını topla: kontrolün varlığını ekran değil sonuçla doğrulayın

4. Öncelikli iyileştirme planı yap: sorumlu, tarih ve bütçeyi atayın

5. Olay senaryosunu tatbik et: iletişim ve geri dönüş adımlarını süre tutarak deneyin

6. Kalan riski yönetimle kabul et: ertelenen riskin nedenini kayıt altına alın

Adımların sırası önemlidir. Ürün satın alındıktan sonra ihtiyaç analizi yapmak, işletmeyi cihazın sınırlarına uydurur. Önce mevcut durum kaydı, ardından tasarım, kontrollü uygulama ve kabul testi yapılırsa sorun çıktığında hangi değişikliğin etkili olduğu anlaşılır. Yapılandırma yedeği, as-built dokümanı ve yetki matrisi teslim dosyasının parçası olmalıdır.

e-ticaret operasyonu için örnek uygulama senaryosu

e-ticaret operasyonu ortamında Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü ihtiyacının ortaya çıktığını düşünelim. İlk talep çoğu zaman tek bir ürün veya arıza üzerinden gelir. Keşif sırasında kullanıcıların günlük çalışma biçimi, yoğun saatler, uzaktan erişim gereksinimi ve kritik verinin nerede bulunduğu incelenir. Aynı ihtiyacı karşılayan iki tasarım çıkarılır: birincisi bugünkü yükü, ikincisi planlanan büyümeyi kapsar.

Ekip, iki tasarımı ilk yatırım bedeli dışında kesinti riski, lisans yenileme, yönetim işçiliği ve yedek parça erişimi üzerinden karşılaştırır. Pilot veya kontrollü geçiş yapılabiliyorsa önce sınırlı bir bölümde uygulanır. Sonuçlar kullanıcı geri bildirimiyle değil yalnızca onunla yetinmeden, varlık/risk kayıtları, kontrol kanıtları ve olay tatbikatı üzerinden doğrulanır. Kabulden sonra sorumlu kişiye kısa kullanım eğitimi verilir ve ilk kontrol tarihi belirlenir.

Teklifte bulunması gereken maddeler

  • Hesap ve oturumlar: hedef değer, doğrulama yöntemi, sorumlu ve teslim kanıtı yazıldı mı?
  • Cihaz ve veri: hedef değer, doğrulama yöntemi, sorumlu ve teslim kanıtı yazıldı mı?
  • MFA ve token: hedef değer, doğrulama yöntemi, sorumlu ve teslim kanıtı yazıldı mı?
  • Paylaşılan erişimler: hedef değer, doğrulama yöntemi, sorumlu ve teslim kanıtı yazıldı mı?
  • Tedarikçi ve bulut hesapları: hedef değer, doğrulama yöntemi, sorumlu ve teslim kanıtı yazıldı mı?
  • Denetim kanıtı: hedef değer, doğrulama yöntemi, sorumlu ve teslim kanıtı yazıldı mı?
  • Kullanılacak ürün ve lisansın tam adı, süresi ve yenileme sorumlusu açık mı?
  • Montaj, yapılandırma, test, eğitim ve dokümantasyon kapsamı ayrı ayrı yazıldı mı?
  • Hariç işler, müşteri sorumlulukları ve ek maliyet doğurabilecek koşullar belirtilmiş mi?
  • Garanti başlangıcı, servis tepki yöntemi ve yapılandırma yedeğinin teslim biçimi belli mi?

Maliyet nasıl değerlendirilmelidir?

Danışmanlık, lisans, güvenlik ürünü, log saklama, eğitim, tatbikat ve yönetilen hizmet kalemleri risk azaltma etkisiyle birlikte değerlendirilmelidir.

Satın alma fiyatı ile toplam sahip olma maliyeti aynı değildir. Üç yıllık değerlendirmede cihaz veya yazılım bedeline lisans, bakım, enerji, kablolama, kurulum, personel zamanı, eğitim ve olası kesinti maliyeti eklenmelidir. Bir çözüm ilk gün ucuz görünürken yönetim yükü veya plansız duruş nedeniyle daha pahalı olabilir. Tekliflerin aynı süre ve aynı kapsam üzerinden karşılaştırılması bu nedenle zorunludur.

En sık yapılan hatalar

  • Her riski aynı öncelikle ele almak
  • Politikayı kopyalayıp gerçek iş akışını incelememek
  • Yedek ile geri dönüşü aynı kabul etmek
  • Log toplarken inceleme sorumlusu belirlememek
  • Kullanıcı eğitimini tek seferlik sunum saymak

Bu hataların ortak tarafı ölçüm ve sorumluluk eksikliğidir. “Gerekirse bakılır”, “otomatik çalışır” veya “standart kurulum” gibi ifadeler kabul kriteri değildir. İşin hangi koşulda tamamlanmış sayılacağı, müşterinin hangi bilgiyi sağlayacağı ve servis ekibinin hangi kaydı teslim edeceği sözleşme veya teklif ekinde bulunmalıdır.

Başarı ve bakım göstergeleri

  • Envanteri ve sahibi belirli kritik varlık oranı
  • Çok faktörlü doğrulama kapsamı
  • Kritik zafiyetin giderilme süresi
  • Olay algılama, sınırlama ve normale dönüş süresi
  • Tatbikat sonrası kapanan iyileştirme maddeleri

Ölçüm yalnızca kurulum günü yapılmamalıdır. İlk hafta, ilk ay ve kapasite değişikliklerinde kontrol tekrarlanmalıdır. Güncelleme, lisans, yedekleme ve alarm kayıtları düzenli gözden geçirilmezse iyi tasarlanmış bir sistem zaman içinde görünmeden zayıflar. Bakım sonucu bulunan sapmalar için sorumlu ve kapanış tarihi atanmalıdır.

Sık sorulan sorular

Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü için ilk adım nedir?

İlk adım ürün seçmek değil, mevcut sistemi ve iş hedefini kayda almaktır. hesap ve oturumlar için bugünkü durum ve kabul edilecek sonuç yazılmadan model veya paket karşılaştırması yapılmamalıdır.

Cihaz ve veri nasıl doğrulanır?

Uygulama öncesi ve sonrası aynı yöntemle ölçüm yapılmalı; tarih, araç, kapsam ve sorumlu bilgisi test tutanağına eklenmelidir. Mevzuat ve sözleşme yükümlülüğü sektör ve veri türüne göre değişebilir; hukuki gereklilikler yetkili uzmanla doğrulanmalıdır.

En ucuz teklif neden yeterli olmayabilir?

Teklifler lisans, kurulum, bakım, dokümantasyon ve hariç işler bakımından farklı olabilir. MFA ve token aynı kapsamda yazılmadığında toplam sahip olma maliyeti karşılaştırılamaz.

Kontrol ne zaman tekrarlanmalıdır?

İlk hafta ve ilk ay kontrolüne ek olarak kullanıcı, cihaz, internet hattı, yazılım sürümü veya fiziksel ortam değiştiğinde test yenilenmelidir. Kritik alarm ve lisans tarihleri merkezi olarak takip edilmelidir.

DKAVİS bu süreçte hangi kayıtları teslim eder?

İşin kapsamına göre keşif notu, ürün veya lisans listesi, yapılandırma özeti, test sonucu, servis formu ve bakım önerileri hazırlanır. Gizli erişim bilgileri yalnızca yetkili kişilerle güvenli kanaldan paylaşılır.

Sonuç

Çalışan İşten Ayrıldığında Siber Güvenlik Kontrolü için güvenilir sonuç; doğru üründen önce doğru soruyu sormaya bağlıdır. Mevcut durum ölçülür, risk ve büyüme ihtiyacı yazılır, teklifler aynı kapsamla karşılaştırılır ve teslim ölçülebilir kanıtlarla kabul edilirse yatırım korunur. Karar dosyasının sonunda ürün listesi kadar test sonucu, sorumluluklar, lisans takvimi ve bakım planı da yer almalıdır.

İçerik kontrolü

DKAVİS Teknik Ekibi

Bu rehber, uygulama deneyimi ve ulaşılabilen birincil kaynaklar dikkate alınarak hazırlanmış; anlaşılabilirlik ve teknik tutarlılık açısından kontrol edilmiştir.

Yayın ve güncelleme ilkelerimizi inceleyin →

Kaynaklar ve ileri okuma

Bir sonraki adım

İhtiyacınızı birlikte netleştirelim.

Siber Güvenlik için keşif, proje veya uygulama desteği alın.

Siber güvenlik analizi iste →
WA
AraTeklif AlWhatsApp