GDPR, SOC2 ve Satın Alma Sürecini Hızlandıran B2B SaaS Kontrol Listesi

Bir alıcı "GDPR uyumlu musunuz?" diye sorduğunda, aslında evet veya hayır cevabı bekleyen bir soru sormuyordur. Şirketinizin, satın alma görevlilerinin sözleşmeye eklemesi gereken on belgeyi, dört sicili ve bir denetim günlüğünü sunup sunamayacağını soruyordur. Aşağıdaki kontrol listesi, bir B2B potansiyel müşterisi doğrulama yapmak istediğinde onlara verdiğimiz listedir.

On belge

Bunlar hukuki görüş değildir, ancak tipik bir AB B2B satın alma kontrol listesini, her bir maddeyi destekleyen mühendislik ve politika çalışmalarına eşler:

1. İmzalanmış bir Veri İşleme Anlaşması (DPA). Talep üzerine sunulabilir, karşılıklı uygulanabilir şablon. GDPR Madde 28'i yansıtır.
2. İşleme faaliyetleri kaydı. Amaçları, veri kategorilerini, alıcıları, saklama sürelerini ve yasal dayanağı listeleyen dahili ROPA.
3. Alt işlemci listesi. Alıcı verilerine dokunan her bir tedarikçi, isimleri ve bir değişiklik bildirim süreciyle birlikte.
4. Veri aktarım etki değerlendirmesi (TIA). EEA dışına çıkan tüm veriler için — Batı Kıyası'nda bir alt işlemcisi olan bir ABD SaaS tedarikçisi için bile.
5. İhlal bildirim süreci. Denetim makamına 72 saatlik süre; yüksek riskli ihlallerde veri sahiplerine gecikmeksizin bildirim süresi.
6. Veri sahibi hakları süreci. DSAR taleplerinin alınması, kimlik doğrulaması, yanıt SLA'sı (30 gün) ve bir silme veya dışa aktarma talebini yerine getirmek için gereken mühendislik çalışması.
7. Saklama takvimi. Neyi, ne kadar süreyle sakladığımız, nasıl silindiği ve silme işlemini hangi sistemin yönettiği.
8. Çerez ve takip politikası. Pazarlama sitesinde, ürün uygulamasında, admin panelinde nelerin çalıştığı ve her bir çerezün neden var olduğu.
9. Güvenlik genel bakış belgesi. İletim halindeki şifreleme, beklemedeki şifreleme, anahtar yönetimi, erişim kontrolü, olay müdahalesi.
10. Erişilebilirlik duruşu. Çalışma süresi taahhütleri, nelerin kapsam dışı olduğu (adil bir SLA) ve felaket kurtarma senaryosu.

Her bir maddeyi destekleyen mühendislik çalışması

On belgeyi okuyan bir alıcı, daha sonra mühendislik ekibinden uygulamayı üzerinden geçmelerini isteyecektir. Aslında en sık karşılaşılan sırayla, bariz olmayan maddeler:

Veri Sahibi Erişim Talebi (DSAR) yerine getirme

Alıcı, kimlik doğrulamasının zorunlu olduğu, denetim günlüğüne kaydedilmiş silme ve dışa aktarma uç noktalarınızı görmek ister. Mühendislik çalışması:

• Hesabı iptal eden, kişisel verileri temizleyen ve kişisel verilerin kendisi olmadan bir denetim günlüğü girişi tutan bir DELETE /api/users/{id}.
• Kullanıcıya atıfta bulunan her bir varlığın makine tarafından okunabilir bir arşivini döndüren bir GET /api/users/{id}/export.
• Her ikisinde de kimlik doğrulaması — e-posta mevcut olmasa bile bcrypt zaman eşitlemesi (böylece yanıt süresi kullanıcı numaralandırmasını ifşa etmez).

Alt işlemci yönetimi

Alıcı bir liste ve bir değişiklik bildirim süreci ister. Mühendislik çalışması:

• Dokümantasyonda değişiklikler için bir RSS akışı veya webhook içeren versiyonlanmış bir alt işlemci listesi.
• Verileri belgelenmiş listenin dışına gönderen bağımlılıkları reddeden bir kod yolu (bir CI kontrolü veya çalışma zamanı izin listesi).

Çıkarım ve depolama için AB yerleşimi

Birçok B2B alıcısı, ana veritabanı ABD'de bulunan bir SaaS'ı satın almayacaktır. Mühendislik çalışması:

• MongoDB bölgesini AB'ye sabitlemek (eu-west-1 veya benzeri).
• Herhangi bir üçüncü taraf çıkarım sağlayıcısını bir AB uç noktasına sabitlemek ve bunu DPA'da belirtmek.
• Veri yerleşikliğini güvenlik genel bakışında belgelemek.

Saklama zorunluluğu

Çoğu startup bir saklama politikası oluşturabilir. Daha zor soru şudur: "Bu uygulanıyor mu?" Mühendislik çalışması:

• Saklama süresi dolmuş kayıtları tarayan ve onları silen planlanmış bir iş (scheduled job).
• Talep üzerine alıcıya erişilebilen iş günlüğü.
• İşin çalıştığına dair açık bir test (sadece derlendiğine dair bir CI doğrulaması değil).

Denetim günlüğü

Neredeyse her güvenlik anketi bunu ister. Mühendislik çalışması:

• Bir interceptor veya middleware tarafından beslenen, eklemeye dayalı (append-only) merkezi bir denetim günlüğü varlığı.
• Saklama süresi: Alıcının beklediğinden daha uzun (varsayılan 30 gün, yapılandırılabilir üst sınır). Asla daha kısa değil.

Admin panelinde erişim kontrolü

Alıcılar, şirketinizde kimin verilerini görebileceğini bilmek isterler. Mühendislik çalışması:

• Rolleri, her roldeki kişileri ve erişim izini belirten belgelenmiş bir erişim politikası.
• Üretim erişimi için kısa bir TTL (talep üzerine gerekçe yorumuyla verilen 4 saatlik TTL kullanıyoruz).

Tuzak: Bir hedef olarak SOC 2 vs. sürekli bir uygulama

Çoğu erken aşama B2B SaaS şirketinin yaptığı hata, SOC 2'yi bir bitiş çizgisi olarak görmektir. Öyle değildir. SOC 2 denetimleri belirli bir zaman dilimi içindir; alıcı sadece en son denetim raporunu değil, sürekli kontrol duruşunuzu okuyacaktır. Bunu sürekli kılan mühendislik çalışması:

• Saklama zamanlayıcısı, bir doğrulama işi olarak CI'da çalışır (sorgu güncel olmayan sonuçlar döndürüyor mu?).
• Denetim günlüğü kayıtları, birinin gerçekten izlediği bir paneli besler.
• Alt işlemci listesi, her sürümde bağımlılık kilit dosyasından (dependency lockfile) otomatik olarak yeniden oluşturulur.

A alıcı bu sinyalleri doğrudan okur. "Bana paneli göster" diyeceklerdir. Panelin hazır olsun.

Alıcının aslında önem verdiği şeyler

Beş B2B satın alma döngüsü boyunca edindiğimiz deneyimlere göre, alıcılar şu sırayla üç şeyi önemserler:

• Görünürlük. "Bir şey değiştiğinde bunu görebilir miyim?" (alt işlemci değişiklikleri, ihlal bildirimleri, politika güncellemeleri).
• Geri döndürülebilirlik. "Ayrıldığımda verilerimi alabilir miyim ve verilerimi silebilir misiniz?" (veri dışa aktarma, veri silme, saklama takvimi).
• Orantılılık. "Güvenlik duruşu, size emanet ettiğimiz verilerle orantılı mı?" (şifreleme, erişim kontrolü, denetim günlüğü).

Yukarıdaki kontrol listesinde bu üçünden birine hizmet etmeyen her şey süstür. Onu çıkarın.