DSAR self-service portalı uçtan uca
Devotel Orbit, ilgili kişi taleplerini iki intake yolu üzerinden kabul eder: operatörlerinizin bir kişi adına file yapması ve ilgili kişinin kendi başvurduğu public portal. Tek bir kuyruk ikisini besler. Bu rehber portal yolunu link yayınlamadan yerine getirilmesine kadar izler ve operatör-file ile nasıl birleştiğini gösterir. DSAR referansı (EN) endpoint yüzeyini ve public e-posta/telefon claim durum makinasını belgeler; bu sayfa üzerinden çalıştığınız runbook’tur.Buradaki her kontrol tenant’a aittir: siz linki yayınlarsınız, siz
kuyruğu yürütürsünüz, siz karar verir ve yerine getirirsiniz. Orbit
portalı barındırır, iki faktörlü OTP ile kimlik kanıtı sağlar ve
yasal süreleri takip eder — cevap verme yasal yükümlülüğü sizde,
veri sorumlusunda, kalır. Yükümlülüklerinizi hukuk danışmanınızla
netleştirin.
1. İki intake yolu, tek kuyruk
Operatör-file. EkibinizPOST /compliance/dsar ile ya da
Settings → Compliance → DSAR içindeki Create DSAR diyaloğu ile
talebi file eder. Bu yoldan file edilen talep
verification_status: pending olarak başlar — operatör kimlik
incelemesini onaylamadan veya reddetmeden export ya da silme
workeri dokunmaz. Bu yol şu an uygundur: tanıdığınız kişiler (oturum
açık bir müşteri, workspace’inizdeki bir contact) ve public form
taşıyamayacağı haklar (correction, limit-sensitive-PI,
non-discrimination).
Public self-service portal. İlgili kişi talebini barındırılan
public sayfa üzerinden kendisi file eder — hesap yok, API anahtarı
yok, oturum yok. Sayfa kimliği kuyruğa herhangi bir şey girmeden
önce iki faktörlü e-posta + SMS OTP ile doğrular, böylece bir portal
file önceden doğrulanmış olarak gelir ve export/silme workeri hemen
başlar.
İkisini de çalıştırın. Portal tüketici hacmini sıfır operasyon
dokunuşa götürür; operatör-file portalın çevreleyemediği uç
dosyalarını kapsar. İki yolun da talebi aynı Settings → Compliance →
DSAR listesine ve aynı GET /compliance/dsar yanıtına düşer — tek
kuyruk, tek SLA bannerı, tek audit zinciri.
2. Portal turu
Linki yayınla
Portalı gizlilik politikanız, site footer’ınız veya üründeki privacy center’da “Gizlilik talebi gönder” linki olarak yayınlayın:<locale> her Orbit web sayfasının taşıdığı aynı locale
prefix’idir (en, fr, de, …). Sayfa iki adımlı identifier formunu
Cloudflare Turnstile bot kontrolünün ardında render eder: kişi
e-posta ve telefonunu (E.164) girer, bir talep türü seçer ve kimlik
kanıtı başlar.
Gönderici e-posta önkoşulu
Portal doğrulama kodlarının hangi adreslerden gönderileceğini link canlıya çıkmadan önce kararlaştırın — göndericisi ayarlanmamış bir portal public’te kapalı kalır. İki platform-seviye gönderici API ortamınızda bir kez yapılandırılır:
SMS gönderici yoksa ve platform fallback yoksa, telefon adımı
503
döner ve portal “geçici olarak kullanılamıyor” mesajı gösterir;
e-posta teslim anahtarı yoksa e-posta adımı da aynı şekilde düşer.
Üretimde ilk adım ayrıca bir Turnstile token ister — Cloudflare
dashboard’undan (Turnstile → Add site) alınan
DEVOTEL_TURNSTILE_SECRET_KEY API’de ve
NEXT_PUBLIC_DEVOTEL_TURNSTILE_SITE_KEY web dağıtımında ayarlanır.
SMS doğrulama kodları Devotel softswitch üzerinden platform OTP’si
olarak gider — tenant’a faturalanan trafik değildir.
İlgili kişi ne görür
Kişi beş adımlı bir claim tamamlar; iki kanıt yerleşene kadar kuyruğa hiçbir şey girmez:- Begin — e-posta, telefon (E.164), talep türü. E-posta OTP’si hemen gönderilir.
- Verify email — 6 haneli e-posta kodu (10 dakikalık TTL, 3 deneme, 60 saniye yeniden-gönder soğutması).
- Send phone code — aynı telefona SMS OTP (gönderiler arasında 60 saniye soğutma).
- Verify phone — 6 haneli SMS kodu.
- Submit — talep kuyruğunuza ancak iki kanıt birden ile gelir. Tüm claim’in uçtan uca TTL’i 30 dakikadır.
Identifier’ler workspace’inizde hiçbir contact’a uymuyorsa, submit
adımı yine aynı şekilde döner — portal asla bir contact’in var olup
olmadığını açıklamaz — ve audit satırı platform ölçeğinde yazılır ki
forensic iz eşleşme olmayan durumda da yaşasın.
Jurisdiction SLA saatine mapplenir
Kişi talebinin düştüğü jurisdiction’ı seçer; bu seçim hem satırın taşıyacağı yasal saati hem de kuyruğun tutabileceğirequest_type
değerlerini belirler:
Eşleştirmeyi doğru yapmak önemli:
opt_out_sale ve
limit_sensitive_pi için GDPR eşleniği yoktur ve operatörün default
jurisdiction’ı gdpr’dir — Kaliforniyalı tüketicilerde açıkça
ayarlayın. Portal opt_out file’ının jurisdiction’ını tam da GDPR
varsayılanı aksi halde geçersiz olacağı için CCPA/CPRA’ya
varsayılar. Kişinin yanlış seçimi düzeltilebilir: kuyruktan
jurisdiction’ı yeniden sınıflandırın, SLA rozeti yeniden yerine
oturur.
3. Bir file sonrası operatörler ne görür
Bir contact’a uyan portal file’i Settings → Compliance → DSAR’da operatör-file’larıyla yan yana düşer. OTP kimliği zaten kanıtladığı içinverification_status: verified olarak gelir — onay/red geçidi
onu bloklamaz.
- Durum ve deadline. Satır normal yaşam döngüsü durumunu ve
jurisdiction penceresine yerleşmiş Day X of N SLA rozetini
taşır; herhangi bir ihlal workspace seviyesindeki SLA bannerını
yakar.
GET /compliance/dsar/slaaynı resmi API üzerinden verir. - Silme sınıfı file’lar. “delete” seçen bir kişi Erasure requests (Art. 17) sekmesinin portal bölümünde, SLA rozeti yanında, varsayılan 7 günlük cooling-off penceresinin önünde görünür.
- Yerine getirme. Bir access ya da portability file’ı signed
export_urlile Completed’a ulaşır; Download decrypted aksiyonu operatör için plaintext export’u derler. Bir silme, yürütüldükten sonra Proof of deletion sertifikasını ve bağlı hedeflerinize Propagate’i sunar. - Audit zinciri. Begin, iki doğrulama ve submit; hashlenmiş (asla ham değil) identifier’lar, kaynak IP ve user agent ile satırlar yazar — bir regülatör kimliğin nasıl kurulduğunu sorduğunda evidence binder (EN) içinden çektiği kayıt budur.
4. Orbit ne yapmaz
Portal, intake ve kimlik kanıtı makinesidir; yasal kararlar sizde kalır:- Orbit geçerliğe asla karar vermez. Bir talebi yasal gerekçelerle asla kabul etmez veya reddetmez. Verification pending satırları sizin onay/red kararınızı bekler; verified satırlar yerine getirilir çünkü siz izin verirsiniz, platform claim’i yargıladığı için değil.
- Orbit operatör hükmünü asla otomatik yerine getirmez.
Operatör-file bir talepte
verification_status: pendingiken export üretilmez, hiçbir şey silinmez. Bir portal file’ı geçidi yalnızca OTP’si kimliği zaten kanıtladığı için atlar. - Silme, cooling-off pozisyonunuza saygı duyar. 7 günlük varsayılan (tenant başına override edilebilir) size imhadan önce reddetme, tutma veya muaf tutma penceresi verir.
- Hangi kanunun uygulandığını söylemek hâlâ hukuk danışmanınızın işi. Orbit SLA saatini, kişinin seçtiği ve sizin onayladığınız jurisdiction’a bağlar.
- Portal tüketici dostu haklar alt kümesini yüzeyler — operatör-only bir hakka (correction, limit-sensitive-PI, non-discrimination) ihtiyacı olan kişi ekibiniz üzerinden file eder.
Portal claim döngüsü — çalıştırılabilir istek örnekleri
Portalın altı kimliksiz verb’i/api/v1/compliance/public/dsar
altında yaşar (tam yüzey: DSAR referansı (EN)).
Bu, portal sayfasının çalıştırdığı zincirin aynısıdır ve uçtan uca
script’lenebilir — linki yayınlamadan önce bir dağıtımı smoke-test
etmek veya bir regülatöre kimlik kanıtı yolunu göstermek için
kullanışlıdır. API anahtarı yoktur: OTP çifti kanıtın kendisidir,
bu yüzden herhangi bir operatör anahtarı public çağrıyı zayıflatır.
1. Claim’i başlat
202
claim_id’yi saklayın — sonraki her adım ona referans verir. Yanlış
e-posta formatı, E.164 dışı telefon veya hatalı Turnstile token 422 VALIDATION_ERROR döner; IP-başına ve e-posta-başına geçitler
Retry-After header’ı ile 429 döner. Begin adımı çift bir
contact’le eşleşsin ya da eşleşmesin aynı şekilde cevap verir —
çağıranlar contact ikililerinizi enumerate edemez.
2. E-posta kodunu doğrula
200
422
422 mesajını döner (“Code expired. Please request a new
one.”, “Too many attempts. Please start over.”) — POST /api/v1/compliance/public/dsar/resend-email 60 saniyelik cooldown
sonrasında taze bir e-posta kodu verir.
3. Telefon kodunu gönder ve doğrula
Retry-After ile
429 döner. Ardından:
200
4. İki kanıt yerleşikken submit et
201
queued: true, çiftin bir workspace contact’iyle eşleştiği ve
talebin kuyruğunuza girdiği anlamına gelir; queued: false eşleşmeme
durumudur — aynı şekil, yani bir çağıran ayırt edemez. İki kanıt
geçmeden submit ederseniz “Both verification steps must complete
before submission.” ile 422 alırsınız. dsar_pub_… referansı audit
satırı id’sidir; evidence binder (EN)‘ın
çektiği identifier’ın aynısı.
5. Operatör kuyruğunda geri oku
Operatör tarafı owner/admin API anahtarı veya aynı seviyede bir dashboard oturumu ister:200
access →
know) ve verification_status: verified olduğuna dikkat — sizi
bekleyen bir intake geçidi yok.
Yasal deadline, SLA payload’unun işidir:
200
sla_deadline_at, dashboard’un Day X of 30 rozetinin yerleştiği mutlak
vade tarihidir; breach_count > 0 workspace banner’ını yakan değerdir.
Bunların hiçbiri talebi yerine getirmez — kuyruk, hüküm ve yerine
getirme hâlâ sizindir; bu döngü yalnızca kişinin iddia ettiği kişi
olduğunu kanıtlar ve file’ını doğru saate düşürür.
5. Uçtan uca örnek — bir GDPR access talebi
Berlin’de bir müşteriniz gizlilik politikanızı açar, portal linkine dokunur ve tuttuğunuz her şeyi ister. Sıra:- Begin. E-postasını ve E.164 telefonunu (
+4915…) girer, access seçer ve Turnstile kontrolünü geçer. Portal bir claim id döndürür; e-posta OTP’si zaten yoldadır. - Verify email. 6 haneli kodu (10 dakikalık TTL, en fazla 3 deneme) okur ve ilk faktörü geçer.
- Send phone code, Verify phone. İkinci faktör SMS ile tekrarlar — gönderimler arasında 60 saniye soğutma — ve her iki kanıt da artık yerleşiktir.
- Submit. Portal talebi file eder. E-posta ve telefonu
workspace’inizdeki bir contact ile eşleştiği için satır
gdpraltındaknowolarak kuyruklanır vedsar_pub_…referansı döner. - Kuyruğunuzda. Satır Day 1 of 30 gösterir —
verification_status: verified— ve export workeri zaten üzerindedir. Ekibiniz triage’e hiç dokunmaz. - Yerine getir. Worker export’u derler ve satırı
export_urlile Completed işaretler. Bir operatör indirme linkini teslim eder (operatör-only plaintext kopyası Download decrypted ile bir tık). - SLA çizgisinin üzerinde. Satır 30 günlük GDPR penceresi dolmuşken açık kalırsa, workspace SLA bannerı onu işaretler — ve intake sırasında yanlış jurisdiction seçilmişse, kuyruk yeniden sınıflandırması saati geriye dönük düzeltir.
İlgili referanslar
- DSAR referansı (EN) — tam operatör ve public endpoint yüzeyleri, abuse-defence sınırları ve SLA severity kademeleri.
- DPO & AB/BK temsilcisi ataması (EN) — bir gizlilik bildiriminin adıyla anması gereken Art.37/Art.27 atamaları.
- GDPR işleme kaydı (ROPA + DPIA) (EN) — herhangi bir talep gelmeden önce tutulan Art.30 envanteri.
- Compliance evidence binder (EN) — portal file’ının geride bıraktığı audit satırlarını derleme.
- DSAR yerine getirme ve breach incident register’ını işletme (EN) — portalınızın beslediği kuyruğun operatör turu.
- GDPR posture’unu uçtan uca derleme (EN) — portal intake’inin tam dizideki yeri.