SOC 2 Hazırlığı: Trust Services Criteria, Type 1 ve Type 2

ABD merkezli bir müşteriye yazılım veya yönetilen hizmet satarken satın alma sürecinin bir noktasında aynı soru gelir: “SOC 2 raporunuz var mı?” ISO 27001 belgeli bir şirket bunu çoğu zaman “bir sertifika daha” diye okur ve hazırlığı hafife alır. Hata burada başlar. SOC 2’nin yapısı, kanıt beklentisi ve zaman çizelgesi farklıdır. Aşağıda rapor yapısını, Trust Services Criteria kategorilerini, Type 1 ile Type 2 farkını ve ISO 27001’den gelen bir şirketin hazırlığı nasıl planlaması gerektiğini anlatıyoruz.

SOC 2 nedir, kim talep eder?

SOC 2, Amerikan Yeminli Mali Müşavirler Enstitüsü AICPA tarafından tanımlanan bir güvence raporudur. Bir hizmet kuruluşunun (service organization) belirli bir sistemiyle ilgili kontrollerinin Trust Services Criteria’ya göre uygun tasarlandığına, Type 2’de ayrıca etkin işlediğine dair bağımsız bir denetçinin görüşünü içerir. Denetimi, SSAE 18 kapsamındaki güvence standartlarına göre lisanslı bir CPA firması yürütür.

Talep genellikle SaaS sağlayıcılarının kurumsal müşterilerinden, veri merkezi veya yönetilen hizmet alan şirketlerden ve müşteri verisini işleyen tedarikçilerle çalışan kuruluşlardan gelir. Rapor kısıtlı dağıtımlıdır; müşteriyle genellikle gizlilik sözleşmesi altında paylaşılır.

Bir SOC 2 raporu tipik olarak şu bölümlerden oluşur:

• Bağımsız denetçi raporu: Denetçinin görüşü; şartlı görüş varsa gerekçesi.
• Yönetim beyanı: Şirket yönetiminin sistem tanımının doğruluğuna ve kontrollere ilişkin beyanı.
• Sistem tanımı: Hizmet, altyapı, yazılım, insanlar, süreçler, veri; alt hizmet kuruluşları ve tamamlayıcı kullanıcı kontrolleri (CUEC).
• Kriterler, kontroller ve test sonuçları: Her kontrol, denetçinin uyguladığı test ve sonuç; varsa istisnalar.

Trust Services Criteria kategorileri

Trust Services Criteria beş kategoriden oluşur. Security her raporda zorunludur. Diğerleri kapsam kararıdır.

Kategori	Odak	Ne zaman kapsama alınır?
Security (ortak kriterler)	Yetkisiz erişime ve hasara karşı koruma	Her zaman
Availability	Taahhüt edilen kullanılabilirlik	SLA veya erişilebilirlik taahhüdü varsa
Processing Integrity	İşlemenin eksiksiz, doğru, zamanında olması	Hizmet, müşteri adına işlem/hesaplama yapıyorsa
Confidentiality	Gizli olarak belirlenen bilginin korunması	Sözleşmeyle gizlilik taahhüdü varsa
Privacy	Kişisel verinin toplanması, kullanımı, saklanması, imhası	Kişisel veri işleme taahhüdü varsa, özellikle veri doğrudan kişiden toplanıyorsa

Security kategorisinin ortak kriterleri (Common Criteria) CC1–CC9 olarak gruplanır: kontrol ortamı (CC1), iletişim ve bilgi (CC2), risk değerlendirmesi (CC3), izleme faaliyetleri (CC4), kontrol faaliyetleri (CC5), mantıksal ve fiziksel erişim (CC6), sistem operasyonları (CC7), değişiklik yönetimi (CC8) ve risk azaltma (CC9). İlk beş grup COSO iç kontrol çerçevesinin bileşenlerini izler. Bu yüzden SOC 2, ISO 27001’e göre yönetişime ve kontrol ortamına daha fazla ağırlık verir; teknik ekipler hazırlıkta en çok CC1 ve CC2 kanıtlarında zorlanır.

Type 1 ve Type 2 farkı

Özellik	Type 1	Type 2
Kapsadığı zaman	Belirli bir tarih	Bir dönem (gözlem dönemi)
Görüş konusu	Kontrollerin uygun tasarımı	Tasarım ve dönem boyunca işletim etkinliği
Test yöntemi	Walkthrough, tasarım incelemesi	Dönemden örneklem ile işletim testi
Müşteri nezdindeki değeri	Başlangıç güvencesi	Genellikle beklenen rapor

Standart, Type 2 gözlem dönemi için tek bir süre dayatmaz. Uygulamada ilk raporda daha kısa bir dönem, sonraki yıllarda on iki aylık dönem yaygındır; süreyi denetim firması ve müşteri beklentisiyle birlikte belirleyin. Raporun bitiş tarihi ile müşterinin talep tarihi arasında boşluk kalırsa denetim firması değil, şirket yönetimi bir “bridge letter” (köprü yazısı) verir ve bu aralıkta önemli bir değişiklik olmadığını beyan eder.

İşletim etkinliği testinin mantığı kontrol etkinliği testi rehberinde ayrıntılı anlatılıyor. Type 2 hazırlığında aynı testi şirket içinde önceden koşturmak, denetçinin bulacağı istisnaları erkenden görmenin en ucuz yoludur.

ISO 27001 ile örtüşme tablosu

ISO 27001 belgeli bir şirketin kontrollerinin büyük kısmı SOC 2’de yeniden kullanılır. Fark kontrollerin nasıl tanımlandığında ve nasıl kanıtlandığındadır.

SOC 2 alanı	ISO/IEC 27001:2022 karşılığı	Dikkat edilecek fark
CC1 Kontrol ortamı	Madde 5, Ek A 6.1–6.4	Yönetim kurulu gözetimi ve etik kurallar daha açık kanıt ister
CC3 Risk değerlendirmesi	Madde 6.1, 8.2	Dolandırıcılık riski ayrıca değerlendirilmelidir
CC6 Erişim	Ek A 5.15–5.18, 8.2, 8.5	Her işe giriş/çıkış ve gözden geçirme örneklemle test edilir
CC7 Operasyon ve olay	Ek A 5.24–5.28, 8.15, 8.16	İzleme alarmlarının ele alındığına dair kayıt beklenir
CC8 Değişiklik	Ek A 8.32	Her değişiklikte onay ve test kanıtı aranır
CC9 Risk azaltma	Ek A 5.19–5.22, 5.30	Alt hizmet kuruluşlarının SOC raporları incelenmelidir

Pratik fark şu: ISO 27001 belgelendirme denetimi yönetim sisteminin işlediğini örneklerle doğrular; SOC 2 Type 2 ise her kontrol için tanımlı bir örneklem alır ve istisnaları tek tek raporlar. Bu yüzden SoA’daki kontrol tanımları SOC 2 için genellikle yeterince kesin değildir. Uygulanabilirlik bildirgesi “erişim yetkileri periyodik gözden geçirilir” derken, SOC 2 kontrolü “üretim veritabanı erişimleri üç ayda bir sistem sahibi tarafından gözden geçirilir, kaldırılması gereken yetkiler on iş günü içinde kaldırılır” gibi sıklık, sorumlu ve süre içermelidir. “Periyodik” kelimesi test edilemez.

Hazırlık değerlendirmesi adımları

1. Sistem ve sınır tanımı: Rapor hangi hizmeti kapsıyor? Hangi uygulamalar, veritabanları, bulut hesapları, lokasyonlar ve ekipler içeride? Kapsamı müşteriye sunulan hizmetle sınırlamak iş yükünü belirleyen ilk karardır. Sahada en sık gördüğümüz hata, kapsamı “bütün şirket” diye açıp sonra gözlem döneminde boğulmak.
2. Kategori seçimi: Security’ye ek olarak sözleşmelerdeki taahhütlere göre diğer kategorileri belirleyin.
3. Alt hizmet kuruluşları: Bulut sağlayıcısı, veri merkezi, kimlik sağlayıcı gibi taraflar için carve-out (dışarıda bırakma) veya inclusive (dahil etme) yöntemine karar verin. Carve-out yaygındır; bu durumda sağlayıcının kendi SOC raporunun yıllık incelenmesi bir kontrol haline gelir.
4. Kontrol matrisi: Her kriter için bir veya birkaç kontrol yazın: kontrol ifadesi, sahip, sıklık, otomatik/manuel, kanıt. Kanıt matrisi yöntemi burada doğrudan kullanılır.
5. Boşluk analizi: Matristeki her kontrol için iki soruyu cevaplayın: tasarım var mı, kanıt üretiyor mu? Erişim, değişiklik ve operasyon kontrolleri için ITGC yapısı iyi bir başlangıç iskeletidir.
6. Düzeltme: Eksik kontrolleri gözlem dönemi başlamadan önce kurun ve en az bir döngü çalıştırın.
7. Tamamlayıcı kullanıcı kontrolleri: Müşterinin kendi tarafında yapması gerekenleri (örneğin kendi kullanıcılarının erişimini yönetmek) listeleyin; bunlar sistem tanımında yer alır.

Gözlem dönemi ve kanıt toplama

Gözlem dönemi başladığı anda her kontrolün her çalışması kanıt üretir ve sonradan düzeltilemez. Kaçırılan bir üç aylık erişim gözden geçirmesi raporda istisna olarak görünür. Geri dönüşü yok. Bu yüzden dönem başlamadan önce, BT güvenlik uyumu için şu hazırlık tamamlanmış olmalı:

• Her periyodik kontrol için takvim ve hatırlatma (ticket sistemi veya takvim görevi).
• Kanıtların toplanacağı merkezi, erişimi kısıtlı ve sürüm geçmişi tutan bir depo.
• Popülasyon listelerinin (işe girişler, çıkışlar, değişiklikler, olaylar) sistemden nasıl çekileceğinin yazılı tarifi.
• Aylık iç kontrol: ikinci hat, o ayın kanıtlarının eksiksiz olup olmadığına bakar.
• Dönem içinde yapılan sistem değişikliklerinin (yeni bulut hesabı, yeni uygulama) kapsam etkisinin değerlendirilmesi.

Dönem sonunda denetçi popülasyonları ister, örneklem seçer ve kanıtları talep eder. Kanıt dönem boyunca düzenli toplanmışsa bu aşama kısa sürer; geriye dönük kanıt aranıyorsa haftalar alır ve eksikler o zaman ortaya çıkar. İstisna çıkarsa yönetimin yanıtı rapora eklenebilir. Bu yanıt kök nedeni ve alınan aksiyonu net anlatmalı; müşteri rapordaki istisnayı ancak böyle doğru yorumlar.

Kontrol matrisinin ve sistem tanımının hazırlanması için SOC 2 hazırlık ve BT kontrol dokümantasyonu, erişim–değişiklik–operasyon kontrollerinin kurulması için IT genel kontroller (ITGC) çalışması başlangıç noktası olabilir.

Sık sorulan sorular

SOC 2 bir sertifika mı?

Hayır. SOC 2, bağımsız bir denetim firmasının (ABD’de lisanslı CPA firması) belirli bir sistemin kontrolleri hakkında verdiği bir güvence raporudur. Geçti/kaldı belgesi değildir; görüş, istisnalar ve test sonuçları rapor içinde yer alır ve okuyucu bunları kendisi değerlendirir.

Doğrudan Type 2 ile başlanabilir mi?

Başlanabilir. Kontroller zaten olgun ve kanıt üretiyorsa Type 1 adımını atlayıp gözlem dönemini başlatmak mümkündür. Kontrol tasarımında belirsizlik varsa Type 1 veya en azından resmi bir hazırlık değerlendirmesi, gözlem dönemi içinde istisna birikmesini önler.

ISO 27001 sertifikası SOC 2 yerine geçer mi?

Müşteriye göre değişir. Bazı müşteriler ISO 27001’i kabul eder, bazıları özellikle SOC 2 Type 2 raporu ister. İki çerçeve büyük ölçüde örtüşür; ancak SOC 2 kontrol bazında test sonuçlarını raporladığı için müşterinin kendi denetçisine sunabileceği farklı bir güvence türüdür.

Hangi Trust Services Criteria kategorilerini seçmeliyiz?

Security (ortak kriterler) her SOC 2 raporunda zorunludur. Diğerleri müşteri taahhütlerine göre seçilir: SLA ile kullanılabilirlik taahhüdü varsa Availability, müşteri verisinin gizliliği sözleşmeyle güvence altındaysa Confidentiality gibi. Taahhüt edilmeyen bir kategoriyi kapsama almak iş yükünü boşuna artırır.