Son güncelleme: Ağustos 2026

Temel

PCI DSS 4.0.1 nedir? 12 gereksinim grubu ve 2025'te zorunlu olanlar

PCI DSS, kart verisi işleyen her kurumu bağlayan bir güvenlik standardı. v4.0 ile gelen 64 yeni gereksinimin 51'i uzun süre "ileri tarihli" olarak beklemedeydi; 31 Mart 2025'te bu bekleme bitti. Bu yazı, standardın ne istediğini ve o tarihte neyin değiştiğini madde numaralarıyla özetliyor.

PCI DSS kimi bağlar?

Standart, kart sahibi verisini (PAN — kart numarası ve beraberindeki veriler) işleyen, saklayan veya ileten her kuruluşu kapsar: bankalar, ödeme kuruluşları, PSP'ler, e-ticaret siteleri, çağrı merkezleri ve bu ortamlara dokunan hizmet sağlayıcılar. Yükümlülüğün derinliği işlem hacmine ve kart markalarının belirlediği seviyeye göre değişir; küçük bir işletme öz değerlendirme anketi (SAQ) doldururken, büyük bir kurum yetkili bir denetçiyle (QSA) tam denetime girer.

Kapsamı belirleyen şey işlem hacminden çok kart verisinin nereden geçtiğidir. Kart verisi ortamına (CDE) bağlanan her sistem — bir atlama sunucusu, bir log toplayıcı, bir yönetim ağı — kapsama girer. Denetimlerde en sık yaşanan sürpriz, kapsam dışı sanılan bir sistemin CDE'ye erişebildiğinin fark edilmesidir.

Sürüm takvimi: nerede duruyoruz

Tarih	Ne oldu
31 Mart 2024	PCI DSS v3.2.1 emekliye ayrıldı. Geçerli tek sürüm ailesi v4.x oldu.
Haziran 2024	v4.0.1 yayımlandı — v4.0'ın düzeltilmiş ve netleştirilmiş hâli; yeni gereksinim getirmedi.
31 Mart 2025	İleri tarihli 51 gereksinim zorunlu hale geldi.
Bugün	Denetimler bu gereksinimlerin tamamı üzerinden yapılıyor.

Yani "biz v4.0'a geçtik" demek artık yeterli değil. Bir denetime girildiğinde, ileri tarihli maddelerin de yıl boyunca işlediğini kanıtlamak gerekiyor.

12 gereksinim grubu

Standart altı hedef altında on iki gereksinim grubuna ayrılır:

Grup	Ne ister
Req 1	Ağ güvenlik kontrolleri — segmentasyon ve trafik kısıtları
Req 2	Güvenli yapılandırma — varsayılan parola ve gereksiz servislerin kaldırılması
Req 3	Saklanan kart verisinin korunması — maskeleme, şifreleme, saklama süresi
Req 4	Açık ağlarda iletimin şifrelenmesi — TLS ve sertifika yönetimi
Req 5	Kötü amaçlı yazılıma karşı koruma
Req 6	Güvenli geliştirme ve yama yönetimi
Req 7	Bilme ihtiyacına göre erişim kısıtlama
Req 8	Kimlik doğrulama ve MFA
Req 9	Fiziksel erişim
Req 10	Loglama ve izleme
Req 11	Güvenlik testleri — zafiyet taraması, sızma testi, değişiklik tespiti
Req 12	Politika, risk analizi ve olay müdahalesi

31 Mart 2025'te zorunlu olan gereksinimler

Elli bir maddenin tamamını burada saymak yerine, uygulamada en çok iş çıkaranları ve denetimde en sık takılınanları grupladık. Tam liste için kontrol listesi PDF'ini indirebilirsiniz.

Ödeme sayfası güvenliği — en çok konuşulan iki madde

Madde	Ne ister
6.4.3	Ödeme sayfasında çalışan her script yetkilendirilmeli, bütünlüğü güvence altına alınmalı ve envanteri gerekçesiyle tutulmalı.
11.6.1	Ödeme sayfasının içeriğinde ve HTTP başlıklarında yetkisiz değişikliği tespit edip uyarı üreten bir mekanizma çalışmalı.

Bu ikisi birlikte, tarayıcı tarafında kart verisi çalan saldırılara (e-skimming, yaygın adıyla Magecart) karşı konumlanır. Ayrıntısı için Req 11.6.1 yazımıza bakın.

Kimlik doğrulama ve hesap yönetimi

8.4.2	Kart veri ortamına konsol dışı tüm erişimlerde çok faktörlü doğrulama.
8.3.6	Parola uzunluğu en az 12 karakter (sistem desteklemiyorsa 8).
8.6.2	Parolalar koda ya da betiklere gömülemez.
8.6.3	Uygulama ve sistem hesaplarının parolaları periyodik değiştirilmeli.
7.2.4	Kullanıcı hesapları en az altı ayda bir gözden geçirilmeli.
7.2.5	Uygulama ve sistem hesapları da periyodik incelemeye tabi.

Zafiyet yönetimi ve test

11.3.1.1	Yüksek/kritik olmayan zafiyetler de risk analizine göre ele alınmalı — "düşük" diye bırakılamaz.
11.3.1.2	İç zafiyet taramaları kimlik doğrulamalı yapılmalı.
5.3.3	Çıkarılabilir medya için kötü amaçlı yazılım taraması.
5.4.1	Kimlik avına karşı otomatik koruma mekanizması.
6.4.2	Halka açık web uygulamalarında WAF ya da eşdeğer otomatik çözüm — elle inceleme yeterli değil.
6.3.2	Özel yazılım ve üçüncü taraf bileşenlerin envanteri.

Risk analizi ve program yönetimi

12.3.1	Frekansı esnek bırakılan her gereksinim için hedefli risk analizi (TRA): varlık, tehdit, gerekçe ve seçilen frekans belgelenmeli.
12.3.3	Kullanılan şifreleme takımlarının ve protokollerin yıllık gözden geçirilmesi.
12.3.4	Kullanılan teknolojilerin yıllık gözden geçirilmesi — ömrünü tamamlamış bileşen kalmamalı.
12.6.2	Güvenlik farkındalık programının yıllık gözden geçirilmesi; kimlik avı ve kabul edilebilir kullanım dahil.
12.10.7	Kart numarasının olmaması gereken bir yerde bulunması senaryosu olay müdahale planında yer almalı.

12.3.1 çoğu kurumun gözünden kaçıyor. "Periyodik olarak" diyen her maddede frekansı siz belirliyorsunuz — ama bu seçimi yazılı bir risk analiziyle gerekçelendirmek zorundasınız. Denetçi frekansı değil, gerekçeyi soruyor.

Nereden başlamalı

1. Kapsamı netleştirin. CDE'ye dokunan her sistemi çıkarın; kapsam dışı saydığınız sistemlerin gerçekten izole olduğunu doğrulayın.
2. İleri tarihli maddelere karşı bir GAP analizi yapın. Hangi madde uygulanıyor, hangisi kapsam dışı, hangisinde kanıt yok — üç kova yeter.
3. Kanıt üretimini yıla yayın. Denetimde sorulan şey kontrolün bugün çalıştığı değil, yıl boyunca çalıştığıdır.
4. 12.3.1 risk analizlerini yazın. Esnek frekanslı her madde için bir tane.