1. GİRİŞ

SOC 2 (Service Organization Control 2), servis sağlayıcıların müşteri verilerini nasıl güvenli, gizli ve kullanılabilir şekilde yönettiğini doğrulayan bir uyumluluk raporlama çerçevesidir. AICPA (American Institute of Certified Public Accountants) tarafından tanımlanan Trust Service Criteria (Güvenilirlik İlkeleri) — Güvenlik, Erişilebilirlik, İşlem Bütünlüğü, Gizlilik ve Mahremiyet — temelinde hazırlanır. Bulut‑tabanlı servislerin, SaaS firmalarının ve veri işleyen hizmet sağlayıcıların artan önemiyle SOC 2, müşterilere ve düzenleyicilere güvence vermek için yaygın şekilde talep edilir.

Bu neden bugün önemli?

• Bulut ilkeli hizmet modellleri ve üçüncü taraf entegrasyonlar veri sorumluluğunu dağıttı; müşteriler sağlayıcıların kontrolünü kanıtlamasını bekliyor.
• Siber saldırı riski, veri ihlallerinin maliyeti ve regülasyon baskısı SOC 2 benzeri raporlama ihtiyacını artırıyor.
• SOC 2 raporu, kurumsal satış süreçlerinde güven unsuru olarak rekabet avantajı sağlar.

Kimler için önemli?

• SaaS sağlayıcıları ve bulut servis firmaları — müşteri güveni ve kurumsal satış için
• Güvenlik, uyumluluk ve operasyon ekipleri — kontrol tasarımı ve kanıt sağlama için
• Ürün yöneticileri ve CTO'lar — pazar gereksinimleri ve risk yönetimi perspektifi

2. KAVRAMSAL TEMELLER

2.1 SOC 2 nedir — temel tanım

SOC 2, bir denetçi tarafından değerlendirilen ve servis organizasyonunun hangi kontrolleri uyguladığı, kontrollerin etkinliği ve süreçlerin sürekliliği hakkında rapor veren standart bir çerçevedir. SOC 2 raporu Tip I (belirli bir tarihte kontrol tasarımının uygunluğu) veya Tip II (bir zaman diliminde kontrollerin etkinliği) olabilir. Tip II raporları müşteriler ve düzenleyiciler için daha güçlü güvence sağlar.

2.2 Trust Service Criteria (TSC) — 5 ilke

• Security (Güvenlik): Sistemin yetkisiz erişim, kullanım veya değişikliğe karşı korunması.
• Availability (Erişilebilirlik): Sistemlerin kullanılabilir olması ve performans hedeflerini karşılaması.
• Processing Integrity (İşlem Bütünlüğü): Sistemlerin doğru, zamanında ve yetkili işleme sağlaması.
• Confidentiality (Gizlilik): Bilginin yetkisiz kişilerden korunması.
• Privacy (Mahremiyet): Kişisel verilerin biçimine, kapsamına ve kullanıma göre korunması ve düzenleyici uyuma uygunluğu.

2.3 Temel terminoloji

• Control: Riskleri azaltmak için uygulanan politika, prosedür veya teknik önlem.
• Control objective: Kontrolün ulaşmayı hedeflediği spesifik sonuç.
• Complementary user entity controls (CUEC): Hizmet alan organizasyonun sağlaması beklenen kontroller; sağlayıcının kontrolleri yalnızca tüm user‑side kontroller ile birlikte etkilidir.

3. NASIL ÇALIŞIR?

3.1 Denetim süreci genel hatları

1. Scope tanımlama: Hangi sistemler, hizmetler ve TSC ilkeleri rapora dahil edilecek belirlenir.
2. Readiness phase (hazırlık): Gap analysis, kontrol tasarımı ve eksiklerin giderilmesi.
3. Kontrol uygulama ve kanıt toplama: Policy, procedures, logs, configuration snapshots, change records gibi kanıtlar toplanır.
4. Denetim (audit): Bağımsız denetçi (CPA firması) Tip I/Tip II değerlendirmesini yapar.
5. Raporlama: Denetçi raporu ve management assertion (sağlayıcının beyanı) hazırlanır.

3.2 Scope belirleme ve boundary'ler

Scope kararı kritik önemdedir: hangi uygulamalar, ortamlar, cloud hesapları ve üçüncü taraflar denetime dahil edilecek? Örneğin sadece müşteri verisini işleyen API ve veri depoları mı, yoksa tüm CI/CD pipeline mı kapsanacak? Scope ayrıca CUEC tanımlamalarını da etkiler; kullanıcı organizasyonundan hangi destek beklendiği açıkça belirtilmelidir.

3.3 Kontrol örnekleri

• Identity & Access Management: MFA, least privilege, role‑based access.
• Change Management: code review, CI/CD gating, deploy approvals.
• Logging & Monitoring: centralized logs, SIEM, alerting thresholds.
• Backup & Recovery: encrypted backups, restore tests, RTO/RPO hedefleri.
• Encryption: data at rest ve data in transit için uygun algoritmalar ve key management.

3.4 Kanıt toplama

Denetim için gerekli kanıtlar hem teknik (log extractları, config snapshotları, IAM policies) hem de süreçsel (policy dokümanları, eğitim kayıtları, runbook'lar) olabilir. Kanıtların güvenilir olması için zaman damgası, hash ve denetlenebilir kayıtlar kullanılması tavsiye edilir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 SaaS şirketleri için SOC 2

SaaS firmaları genellikle SOC 2 raporunu yeni kurumsal müşteriler kazanmak için zorunlu hale getirir. Tip II raporları, bir zaman dilimindeki kontrol etkinliğini gösterdiğinden, özellikle finans ve sağlık gibi regüle sektör müşterileri için kritik öneme sahiptir. Örnek uygulamalar: müşteri veri izolasyonu, tenant bazlı erişim kontrolleri, logging per tenant.

4.2 Bulut sağlayıcıları ve platform servisleri

Bulut‑native servisler SOC 2 kapsamına alındığında; IAM politikaları, VPC/Network ACL'leri, KMS kullanımı ve altyapı otomasyonu (IaC) gibi kontroller denetim altında değerlendirilir. Otomasyon ve immutable infrastructure, kontrol tutarlılığı sağlamak için iyi uygulamalardır.

4.3 Örnekler: Amazon, Stripe, küçük ölçekli SaaS

Büyük sağlayıcılar kapsamlı raporlar sunabilir; küçük SaaS'lar ise daha dar scope ile başlar (ör. sadece core customer data path). Önemli olan, scope çerçevesinde tutarlı ve tekrarlanabilir kontrollere sahip olmaktır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Müşterilere ve potansiyel ortaklara güvence sunar ve satış döngüsünü hızlandırır.
• Kontrollerin belgelenmesi ve denetlenmesi, iç süreçlerin olgunlaşmasını ve standardizasyonu teşvik eder.
• Regülasyon ve sigorta taleplerine cevap verebilecek dokümantasyon sağlar.

Sınırlamalar

• SOC 2, teknik bir güvenlik sertifikası değil; kontrol tasarımı ve etkinliğinin bir anlık veya dönemsel değerlendirmesidir.
• Tip II raporu için gerekli kanıtların toplanması ve sürekliliğinin sağlanması operasyonel maliyet getirebilir.
• Raporun kapsamı dışında kalan sistemler için herhangi bir garanti sunmaz; scope dışı riskler hala söz konusu olabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

7.1 Hazırlık ve road‑map

• Başlangıçta gap assessment yapın: mevcut kontrolleri TSC kriterlerine göre değerlendirin.
• Scope belirlerken müşteri değer zincirini ve kritik veri yollarını önceliklendirin.
• Automation: log collection, configuration management, IaC temelli deploylar ile evidence toplama otomatikleştirilmeli.

7.2 Teknik kontrollere odaklanma

• Identity & access management: least privilege, just‑in‑time access ve gizli anahtar yönetimi.
• Secure SDLC: code review, dependency scanning, SAST/DAST ve supply chain güvenliği.
• Monitoring & incident response: SIEM, SOAR playbook'lar ve düzenli tabletop egzersizleri.

7.3 Organizasyonel uygulamalar

• Policy ve prosedürlerin dokümantasyonu: eğitim, onboarding ve düzenli güncelleme mekanizmaları kurun.
• Change management ve kayıt: değişikliklerin izlenebilirliği, onay ve rollback süreçleri olmalıdır.
• Third‑party risk management: tedarikçi değerlendirmeleri, SLA'lar ve güvenlik gereksinimleri sözleşmeye eklenmeli.

8. SIK YAPILAN HATALAR

• Scope'u çok geniş veya çok dar tutmak: geniş scope maliyetleri artırır, dar scope geçersiz güven sunar.
• Kâğıt üzerinde kontroller: uygulama ve kanıt eksikliği denetimde başarısızlığa neden olur.
• Kanıt toplama manuel ve dağınık yapıldığında denetim maliyeti yükselir; otomasyon eksikliği operasyonu zora sokar.
• CUEC'leri göz ardı etmek: müşteri tarafı kontrollerin eksik varsayılması raporun geçerliliğini etkileyebilir.

9. GELECEK TRENDLER

9.1 Otomasyon ve sürekli uyumluluk

Denetim hazırlık süreçleri daha fazla otomasyon ile sürekli uyumluluğa (continuous compliance) doğru evriliyor. IaC, immutable infra ve signed artifacts ile denetime hazır kanıtlar canlı tutulabiliyor.

9.2 Veri‑odaklı denetim teknikleri

Denetçiler artık sadece policy incelemiyor; telemetri analizi, log korelasyonu ve anomaly detection ile kontrollerin etkinliğini veriyle doğruluyorlar. Bu da loglama altyapısı ve telemetri kalitesinin önemini artırıyor.

9.3 Uyumluluk ve regülasyon entegrasyonu

SOC 2, ISO 27001, GDPR ve sektörel regülasyonlar arasındaki entegrasyon ihtiyaçları artacak; şirketler ortak kontrol setleri oluşturarak çoklu uyumluluk maliyetlerini düşürmeye çalışacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. SOC 2 Tip I ile Tip II arasındaki fark nedir?

   Tip I kontrol tasarımının belirli bir tarihte uygunluğunu değerlendirir; Tip II ise bir süre boyunca (genellikle 6–12 ay) kontrollerin etkinliğini test eder. Tip II müşterilere daha güçlü garanti sunar.

2. 2. SOC 2 raporu almak ne kadar sürer?

   Readiness ve gap remediation sürecine bağlı olarak birkaç aydan bir yıla kadar sürebilir. Tip II için denetim periyodu dahil edilince süre uzar.

3. 3. SOC 2 için hangi kontroller önceliklidir?

   Identity & Access Management, Logging & Monitoring, Change Management, Encryption ve Backup/Recovery kontrolleri genellikle en kritik kabul edilenlerdir.

4. 4. Küçük SaaS şirketi SOC 2'ye nasıl hazırlanmalı?

   Scope'u dar tutarak (core customer data path), temel kontrolleri önce uygulayıp otomasyon ve kanıt toplama süreçlerini kademeli olarak iyileştirerek başlayın.

5. 5. SOC 2 raporu müşterilerle nasıl paylaşılır?

   Rapor genelde gizlidir ve NDA karşılığında müşterilere veya potansiyel müşterilere sunulur. Özet güvenlik beyanları ise halka açık iletişimde kullanılabilir.

6. 6. SOC 2 denetçisi nasıl seçilir?

   CPA lisanslı, deneyimli ve sektörünüzde rapor veren denetçiler tercih edilmeli. Denetçinin yaklaşımını, rapor örneklerini ve referanslarını inceleyin.

7. 7. SOC 2, GDPR veya KVKK ile çakışır mı?

   SOC 2 teknik kontroller yönünden GDPR/KVKK'ya yardımcı olabilir ancak veri koruma yasalarının gerektirdiği süreçler ve haklar için ek politikalara ihtiyaç vardır.

8. 8. SOC 2 sonrası sürekli iyileştirme nasıl sağlanır?

   Continuous monitoring, düzenli internal audit, otomatik evidence collection ve düzenli revizyon döngüsü ile sürekli iyileştirme sağlanabilir.

Anahtar Kavramlar

• SOC 2: Servis organizasyonları için Trust Service Criteria bazlı denetim raporu.
• TSC: Trust Service Criteria — Security, Availability, Processing Integrity, Confidentiality, Privacy.
• Tip I / Tip II: Kontrol tasarımı vs kontrol etkinliği raporları.
• CUEC: Complementary User Entity Controls — kullanıcı organizasyondan beklenen kontroller.

Öğrenme Yol Haritası

1. 0–1 ay: SOC 2 TSC'lerini ve temel güvenlik kontrollerini öğrenin; mevcut durumda bir self‑assessment yapın.
2. 1–3 ay: Gap analysis, temel policy dokümantasyonu ve otomatik log toplama altyapısını kurun.
3. 3–6 ay: Kontrolleri uygulayın, kanıt toplama süreçlerini otomatikleştirin ve internal audit hazırlıklarını tamamlayın.
4. 6–12 ay: Tip II denetimi için sürekliliği sağlayın; bulgulara göre süreçleri iyileştirin ve continuous compliance altyapısını kurun.