GDPR, SOC2 ve Satın Alma Sürecini Açan B2B SaaS Kontrol Listesi

Bir alıcı "GDPR'a uygun musunuz?" diye sorduğunda, evet-hayır sorusu sormuyor. Şirketinizin sözleşmeye eklemesi için satın alma görevlisinin ihtiyaç duyduğu on belgeyi, dört kaydı ve bir denetim günlüğünü üretip üretemeyeceğini soruyor. Aşağıdaki kontrol listesi, bir B2B olası alıcısının doğrulamak istediği zaman ona verdiğimiz kontrol listesidir.

On belge

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

1. İmzalanmış Veri İşleme Sözleşmesi (DPA). İstek üzerine karşı imzalanabilir şablon. GDPR Madde 28'i yansıtır.
2. İşleme faaliyetleri kaydı. Amaçları, veri kategorilerini, alıcıları, saklamayı ve hukuki dayanağı listeleyen dahili ROPA.
3. Alt işleyici listesi. Alıcı verilerine dokunan her satıcı, adları ve değişiklik bildirim süreciyle.
4. Transfer etki değerlendirmesi (TIA). EAA dışına çıkan herhangi bir veri için — Batı Kıyısı'nda bir alt işleyicisi olan bir ABD SaaS satıcısı bile.
5. İhlal bildirim süreci. Denetim otoritesine 72 saat son tarih; yüksek riskli ihlallerde veri sahiplerine gecikme olmaksızın son tarih.
6. Veri sahibi hakları süreci. DSAR alımı, kimlik doğrulama, yanıt SLA'sı (30 gün) ve bir silme veya dışa aktarma isteğini yerine getirmek için mühendislik çalışması.
7. Saklama çizelgesi. Ne tuttuğumuz, ne kadar süreyle, nasıl silindiği ve silme işlemini hangi sistemin sahiplendiği.
8. Çerez ve izleme politikası. Pazarlama sitesinde, ürün uygulamasında, yönetici panosunda çalışan ve her çerezin neden var olduğu.
9. Güvenlik genel bakış belgesi. Aktarım sırasında şifreleme, beklemede şifreleme, anahtar yönetimi, erişim kontrolü, olay müdahalesi.
10. Kullanılabilirlik duruşu. Çalışma süresi taahhütleri, hariç tutulanlar (adil bir SLA), felaket kurtarma hikayesi.

Her öğeyi destekleyen mühendislik çalışması

On belgeyi okuyan bir alıcı, ardından mühendislik ekibinden uygulamayı yürütmesini isteyecektir. Gerçekte en sık gelen, sırasıyla görünüşte önemsiz öğeler:

Veri Sahibi Erişim İsteği (DSAR) yerine getirme

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

• Kişisel verileri temizleyen, hesabı iptal eden ve kişisel verileri olmadan bir denetim günlüğü girdisi tutan bir DELETE /api/users/{id}.

• Kullanıcıya referans veren her varlığın makine tarafından okunabilir arşivini döndüren bir GET /api/users/{id}/export.

• İkisi üzerinde kimlik doğrulama — e-posta mevcut olmadığında bile şifreleme-zaman-eşitlenmiş (böylece yanıt süresi kullanıcı numaralandırmasını sızdırmaz).

Alt işleyici yönetimi

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

• Belgelerde sürümlenmiş alt işleyici listesi, değişiklikler için RSS akışı veya webhook.

• Belgelenmiş listenin dışına veri 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 mukimliği

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

• MongoDB bölgesini AB'ye sabitleyin (eu-west-1 veya benzeri).
• Üçüncü taraf çıkarım sağlayıcısını bir AB uç noktasına sabitleyin ve bunu DPA'da yüzeyleyin.
• Güvenlik genel bakışında veri mukimliğini belgeleyin.

Saklama uygulaması

Çoğu start-up bir saklama politikası üretebilir. Daha zor soru "uygulanıyor mu?" Mühendislik çalışması:

• Saklama son tarihlerini geçen kayıtları tarayan ve silen zamanlanmış bir iş.
• İşin günlüğü, alıcının isteği üzerine erişilebilir.
• İşin çalıştığına dair açık bir test (yalnızca derlendiğine dair bir CI iddiası değil).

Denetim günlüğü

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

• Yalnızca ekleme yapılabilen, bir engelleyici veya ara yazılım tarafından beslenen merkezi bir denetim günlüğü varlığı.
• Saklama: alıcının beklediğinden daha uzun (varsayılan 90 gün, yapılandırılabilir yukarı). Asla daha kısa değil.

Yönetici panosunda erişim kontrolü

Alıcılar, şirketinizdeki kimlerin verilerini görebileceğini bilmek ister. Mühendislik çalışması:

• Rolleri, her roldeki insanları ve erişimin denetim izini adlandıran belgelenmiş bir erişim politikası.
• Üretim erişiminde kısa bir TTL (talep üzerine bir gerekçe yorumuyla verilen 4 saatlik TTL kullanıyoruz).

Tuzak: varış noktası olarak SOC 2 vs sürekli pratik olarak

Erken aşamalı çoğu B2B SaaS şirketinin yaptığı hata, SOC 2'yi bitiş çizgisi olarak ele almaktır. O değildir. SOC 2 denetimleri belirli bir andadır; alıcı yalnızca en son denetim raporunu değil, sürekli-kontrol duruşunuzu okuyacaktır. Bunu sürekli yapan mühendislik çalışması:

• Saklama zamanlayıcısı, bir doğrulama işi olarak CI'da çalışır (sorgu eski olmayan sonuçlar mı döndürüyor?).
• Denetim günlüğü yazımları, birisinin gerçekten izlediği bir panoyu besler.
• Alt işleyici listesi, her sürümde bağımlılık kilit dosyasından otomatik olarak yeniden oluşturulur.

Bir alıcı bu sinyalleri doğrudan okur. "Panonu göster" diye soracaklar. Panonuz olsun.

Alıcının gerçekten önemsediği şey

Beş B2B satın alma döngüsündeki deneyimimizde, alıcılar sırasıyla üç şeyi önemser:

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

Yukarıdaki listede bu üçünden birine hizmet etmeyen her şey dekorasyondur. Kesin.